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Objective* 


The  objective*  were  to  provide  a  logistic*  database  structure  that  permits  practical  use  of  historical  and  current 
logistics  information.  The  structure  was  to  be  tested  for  its  use  in  facilitating  the  influence  of  logistics  factors  upon  weapon 
system  design. 

Background 

The  Air  Force  is  concerned  with  the  lack  of  adequate  logistics  consideration  during  the  weapon  system  design 
process.  To  produce  a  weapon  system  with  optimal  coat  and  mission  effectiveness,  logistics  factors  must  be  considered 
very  early  and  throughout  the  system  design  and  acquisition  process.  Recent  DoD  Standards  and  Instructions  have 
indicated  a  strong  commitment  to  consider  logistics  as  an  integral  part  of  the  weapon  system  design  activity. 

The  logistics  information  system  available  to  the  designer  and  logistician  must  be  adequate.  Yet,  for  many  years 
large  amounts  of  logistics  information  and  data  have  been  collected  and  processed  on  many  different  weapon  systems, 
but  this  was  done  mainly  to  improve  the  capability  of  existing  weapon  systems  and  the  information  systems  were  structured 
to  support  that  end.  The  existing  logistics  systems  do  not  provide  timely  responses  to  requests  for  information  or  data, 
there  is  no  traceability  to  the  data  origin,  and  in  many  instances  the  data  are  neither  consistent  nor  accurate  to  the  degree 
that  is  required  to  support  weapon  system  design.  The  Unified  Data  Base  (UDB)  program  was  formulated  to  address  these 
issues. 


The  UDB  development  program  was  conducted  in  three  phases.  In  the  first  phase,  the  detailed  definitions, 
specifications,  standards,  formats,  and  computer  flow  charting  were  addressed  and  completed.  In  accordance  with 
published  DoD  guidance,  the  UDB  elements  were  based  on  Military  Standard  (MIL-STD)  1388-2.  Additional  elements 
were  added  to  allow  for  the  feedback  of  historical  operational  logistics  information  and  to  address  additional  data  needs 
associated  with  common  logistics  support  analysis  techniques.  The  UDB  was  programmed  for  computer  application 
during  the  second  phase.  The  third  phase  consisted  of  the  demonstration,  testing,  and  further  de-bugging  of  the  UDB 
using  two  acquisition  programs  as  test  vehicles. 

Specifies 

This  UDB  development  program  continued  building  on  the  results  of  a  previous  program  that  established  the  need 
for  additional  data  elements  beyond  those  outlined  in  MIL- STD-1388-2  and  on  the  results  of  the  Tri-Services  Logistics 
Support  Analysis  Record  (LSAR)  Working  Group  (which  continuously  reviews  the  logistics  data  needs  and  requirements 
of  all  the  Services).  Specifically,  the  automated  LSAR  requirements  and  the  various  logistics-related  Contract  Definition 
Requirements  List  (CDRL)  items  associated  with  the  C-X  procurement  activity  were  closely  reviewed. 

The  UDB  can  be  accessed  via  computer  terminals,  by  punched  card  input,  or  by  high  speed  printers  (batch 
processes).  About  70  different  computer  terminal  formats  (screens)  were  designed  to  permit  very  efficient  and  timely 
input,  update,  access,  deletion,  etc.  of  logistics  information  for  any  weapon  system  program.  Large  amounts  of  data  input, 
standard  output  reports,  summari rations,  and  CDRL  items  are  best  handled  via  batch  processes.  Ample  subsets  of  the 
data  can  be  safeguarded  from  unauthorised  updating,  inputting,  deleting,  reading,  etc.  Audit  trails  are  maintained  as 
to  who  input,  read,  updated,  etc.  the  information  and  when  and  where  it  occurred. 

The  UDB  was  tested  and  demonstrated  using  the  HH-60  helicopter  and  the  B-1B  aircraft  acquisition  programs. 
The  historical-information  side  of  the  UDB  was  demonstrated  on  the  HH-60  using  previously  generated  data  from  the 
Army.  Some  standard  summary  reports  were  generated  by  the  UDB  from  this  data.  No  potential  HH-60  problem  areas 
were  discovered.  The  current  logistics  information  side  of  the  UDB  is  being  demonstrated  on  the  B-1B  program.  B-1B 
defensive  avionics  maintenance  and  training  information  for  the  operational,  intermediate,  and  depot  levels  of 
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maintenance  are  being  entered  into  the  UDB.  The  training  and  technical-manual  functional  areas  retrieved  this 
information  via  terminals  from  the  UDB  so  that  critical  concerns  could  be  relayed  immediately  to  design  for  appropriate 
design  consideration. 

CsatlndoM  and  Recommendations 

The  objectives  were  attained.  A  logistics  database  structure,  the  UDB,  was  developed.  Its  practicality  was 
demonstrated  by  using  historical  information  on  the  HH-60  program  and  current  information  on  the  B-1B  program.  As 
a  result  of  this  UDB  effort,  both  historical  and  current  logistics  information  can  now  have  more  influence  on  the  design 
of  weapons  systems. 

It  is  recommended  that  the  UDB  be  further  expanded  to  incorporate  more  efficiently  the  Air  Force  Operational  Test 
and  Evaluation  Center  (AFOTEC)  results  into  the  UDB  and,  thereby,  into  the  design  activity.  This  expansion  should 
build  on  the  initial  work  by  a  contractor  to  outline  the  mapping  between  AFOTEC  data  and  UDB  data  and  to  identify 
additional  AFOTEC  data  needs  that  the  UDB  does  not  currently  address.  The  UDB  should  also  be  expanded  to  interface 
more  efficiently  with  computer-aided  design  (CAD)  activities  that  are  themselves  becoming  so  predominate  throughout 
the  aerospace  industry.  Commonality  of  data  elements  between  UDB  and  CAD  databases  should  be  identified,  and 
processes  to  further  introduce  logistics  factors  into  the  CAD  design  activities  should  be  defined. 
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SECTION  I 


BACKGROUND 

POLICY 

DIRECTIVES 

The  need  for  improved  weapon  system  availability,  supportabil ity ,  and 
overall  cost-effectiveness  has  been  a  continuing  concern  of  the  Department  of 
Defense  (DOD) .  DOD  Directive  (DODD)  5000.39,  "Acquisition  and  Management  of 
Integrated  Logistics  Support  for  Systems  and  Equipment,"  establishes  impor¬ 
tant  policy  addressing  this  need.  It  defines  management  and  technical 
activities  to  be  accomplished  throughout  the  weapon  system  acquisition  pro¬ 
cess  with  emphasis  on  Integrated  Logistics  Support  (ILS)  and  Logistics  Support 
Analysis  (LSA) .  Specifically,  DODD  5000.39  stresses  the  need  (a)  to 
effectively  utilize  information  about  existing  operational  equipment  to 
establish  a  Baseline  Comparison  System  (BCS) ,  (b)  to  integrate  LSA  activity 
into  the  overall  system  design  process,  (c)  to  establish  and  maintain  a  common, 
consistent  Logistics  Support  Analysis  Record  (LSAR)  used  to  support  both  ILS 
and  Reliability  and  Maintainability  (R&M)  development  efforts,  and  (d)  to 
verify  the  LSAR  during  operational  service  of  the  weapon  system. 

MILITARY  STANDARD  (MIL-STD)  1388 

Military  Standard  (MIL-STD)  1388  describes  the  LSA  tasks  to  be 
accomplished  during  a  system  acquisition  program  to  satisfy  the  objectives 
of  DODD  5000.39.  In  addition,  MIL-STD-1388  defines  the  LSAR  needed  to 
document  the  results  of  LSA.  In  1973  the  Army  Development  and  Readiness 
Command  (DARC0M)  developed  the  LSAR  Automated  Data  Processing  (ADP)  system 
to  implement  MIL-STD-1388.  DARCOM  Pamphlet  750-16  (DARCOM,  1979)  is  the 
governing  document  for  the  system. 

Lack  of  LSA/LSAR  standardization  between  service  acquisition  efforts 
led  to  the  formation  of  a  Joint  Service  LSA  Working  Group  in  November  1978. 

The  working  group's  efforts  were  specifically  directed  toward  standardization 


of  the  LSAR  input  data  sheets  and  data  element  definitions.  In  June  1981, 
the  working  group  effort  resulted  in  a  draft  revision  of  MIL-STD-1388 .  In 
December  1981,  the  DARCOM  Materiel  Readiness  Support  Activity  (MRSA)  was 
assigned  to  DOD  LSA  Support  Activity  mission.  This  mission  included  the 
requirements  to  develop  a  MIL-STD  on  LSA  documentation  and  a  standard  DOD 
LSAR  ADP  system.  As  a  result,  in  June  1982,  a  draft  MIL-STD-1388-2A  was 
developed.  A  revised  draft  (MIL-STD-1388-2A,  1983)  was  carefully  reviewed  by 
industry  representatives,  and  the  approved  version  is  expected  to  be 
lblished  in  May  1984. 

Concurrent  with  development  of  MIL-STD-1388-2A,  MRSA  has  been  develop¬ 
ing  a  DOD  LSAR  ADP  system.  At  present,  the  concept  for  this  system,  written 
in  American  National  Standard  Institute  (ANSI)  COBOL,  is  for  batch  processing 
of  input  data  resulting  in  sequential  master  files.  The  difference  between 
the  DOD  LSAR  ADP  system  and  the  DARCOM  750-16  ADP  system  is  that  the  DOD 
system  will  accept  all  inputs  at  a  single  entry  point,  relieving  the 
functional  user  from  having  to  know  which  one  of  the  five  DARCOM  ADP  system 
programs  to  use  for  a  given  input. 

PRODUCT  PERFORMANCE  FEEDBACK  SYSTEM  (PPFS) 

On  27  September  1979,  the  Air  Force  issued  Program  Management  Directive 
(PMD)  L-Y9094(l)  directing  the  definition  and  development  of  a  Product 
Performance  Feedback  System  (PPFS) .  The  primary  objective  of  the  PPFS  is  to 
provide  an  historical  data  repository  of  design-related  information  about 
operational  systems  for  use  by  system  designers,  analysts,  and  support 
planners  involved  in  new  weapon  system  and  equipment  acquisition  programs. 

The  PPFS  will  be  automated  to  provide  convenient  and  timely  access  to  rele¬ 
vant  design,  reliability  and  maintainability  (R&M)  and  support  cost  data  to 
establish  initially  a  baseline  comparison  system  (BCS)  for  the  new  weapon 
system  being  developed.  Once  the  new  weapon  system  becomes  operational,  the 
PPFS  will  provide  performance  data  feedback  to  those  responsible  for 
operation  and  support  (O&S)  throughout  its  life  cycle. 


UNIFIED  DATABASE  TECHNOLOGY 

DEFINITION  STUDY 

During  1978-1979,  the  Logistics  and  Human  Factors  Division  of  the  Air 
Force  Human  Resources  Laboratory  (AFHRL)  conducted  a  study  to  define  the 
requirements  and  establish  a  plan  for  development  of  an  integrated  system 
that  would  assist  in  satisfying  the  requirements  and  objectives  stated  in 
DODD  5000.39.  This  work  by  Thomas  and  Hankins  (1979)  and  Thomas,  Hankins 
and  Newhouse  (1980)  resulted  in  a  concept  and  development  approach  for  the 
Unified  Database  (UDB)  system.  As  conceived,  the  UDB  addressed  the  require¬ 
ments  of  DODD  5000.39,  MIL-STD-1388 ,  PPFS,  and  the  specific  Air  Force 
requirements  associated  with  ILS  throughout  the  weapon  system  acquisition 
process. 

UDB  DEVELOPMENT 

In  January  1980  AFHRL  began  a  three-phased  effort  to  develop  a  proto¬ 
type  UDB  system,  with  each  phase  lasting  approximately  1  year.  The  objective 
of  Phase  I  was  to  accomplish  detailed  definition  and  system  level  design 
of  the  UDB.  The  objective  of  Phase  II  was  to  develop  the  UDB.  The  objective 
of  Phase  III  was  to  test  and  demonstrate  the  UDB.  This  UDB  development 
effort  was  completed  in  March  1983.  This  report  provides  an  overview  of  the 
UDB  concept  and  summarizes  the  results  of  the  development  effort. 
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SECTION  II 
UDB  CONCEPT 

GENERAL 

In  this  section  the  overall  concept  of  the  UDB  is  presented.  It  was 
necessary  to  have  a  global  perspective  of  the  UDB  concept  to  insure  that 
the  "building  blocks"  were  developed  consistent  with  the  overall  objectives. 
The  UDB  development  status  will  be  covered  in  later  sections  of  this  report. 

PURPOSE 

The  purpose  of  the  UDB  is  to  assist  government  and  industry  organiza¬ 
tions  in  accomplishing  the  objectives  of  DODD  5000.39,  M1L-STD-1 388 ,  current 
ILS  reporting  requirements  typically  imposed  on  Air  Force  acquisition  pro¬ 
grams,  and  PPFS. 

OBJECTIVES 

The  primary  objective  of  the  UDB  program  is  to  develop  an  integrated 
system  that  will  provide  mechanisms  (a)  to  establish  and  maintain  an 
historical  data  repository  of  relevant  information  about  operational  weapon 
systems,  (b)  to  enable  convenient  and  timely  access  to  the  historical  data 
repository  and  provide  information  in  a  useful  form  and  content,  (c)  to 
assist  in  establishing  a  BCS  for  use  in  trade-off  studies,  analyses,  and 
predictions  about  the  new  weapon  system  under  development,  (d)  to  assist 
in  developing,  managing,  and  utilizing  a  common  LSAR  throughout  the  acquisi¬ 
tion  process,  (e)  to  provide  convenient  interfaces  between  LSAR  and  standard 
analytical  models  for  predictive  and  planning  purposes,  (f)  to  update  the 
LSAR  with  measured  values  during  the  Operational  Test  and  Evaluation  (OT&E) 
phase,  (g)  to  validate  the  LSAR  using  operational  field  data  during  the  0&S 
phase,  and  (h)  to  utilize  the  UDB  as  a  means  for  product  performance  measure 
ment  and  feedback. 


CONCEPTUAL  APPROACH 


CLOSED-LOOP  SYSTEM 

In  order  to  satisfy  the  UDB  objectives  optimally,  a  closed-loop  system 
is  needed  to  insure  consistency  and  compatibility.  Figure  1  shows  the 
closed-loop  nature  of  the  UDB  in  terms  of  its  objectives  and  the  time-phased 
activities  of  the  weapon  system  acquisition  process. 

Objective  1  -  It  was  concluded  early  in  this  program  (Thomas  et  al . , 
1980)  that  the  Air  Force  should  establish  and  maintain  a  central  Historical 
Data  Repository  (HDR)  for  each  major  product  category  such  as  aircraft, 
missiles,  and  ground  electronics.  The  HDR  will  contain  design,  R&M,  and 
support  cost  information  about  operational  weapon  systems  and  equipment. 

In  the  future,  as  weapon  systems  are  developed  using  the  UDB  concept,  the 
HDR  would  contain  validated  LSAR  for  these  systems. 

The  design  data  in  the  HDR  for  a  given  weapon  system  configuration 
would  remain  constant,  while  the  R&M  and  support  cost  data  would  be 
periodically  updated  using  existing  field  data  collection  systems  such  as 
the  Maintenance  Data  Collection  System  (MDCS) ,  Air  Force  Logistics  Command 
(AFLC)  DO-56  systems,  and  the  Visibility  and  Management  of  Operational 
Support  Cost  (VAMOSC)  system.  If  and  when  modifications  to  a  current  weapon 
system  are  made,  the  design  data  in  the  HDR  will  be  changed  to  reflect  the 
modification,  and  the  corresponding  R&M  and  support  cost  data  in  the  HDR  may 
be  correlated  to  the  modified  design  configuration.  In  this  regard,  main¬ 
tenance  of  the  HDR  will  be  relatively  difficult  until  such  time  that  oper¬ 
ational  weapon  systems  populating  the  HDR  are  developed  using  the  UDB 
concept,  and  therefore  have  an  active  LSAR.  (This  point  will  be  discussed 
later  under  Objective  A.) 

Objective  2  -  The  automated  HDR  will  process  input  data,  as  appropriate 
to  create  output  information  in  the  form  and  content  desired  by  users. 
Information  in  the  HDR  will  be  stored  on  disk  or  on  tape,  as  appropriate. 
Regardless  of  the  data  storage  mechanism,  the  HDR  will  provide  users 


WEAPON  SYSTEM  LIFE  CYCLE 


convenient  and  timely  access  to  selected  information  via  remote  on-line 
cathode  ray  tube  (CRT)  terminals . 

In  the  weapon  system  acquisition  and  support  environment,  convenient 
and  timely  access  to  relevant  data  is  extremely  important.  If  this 
capability  is  missing,  the  utility  and  cost-effectiveness  of  the  HDR  is 
severely  compromised.  There  is  simply  little  value  in  having  an  HDR  loaded 
with  valid  and  useful  information  if  users  cannot  get  it  when  they  need  it. 

Objective  3  -  The  community  of  organizations  involved  with  new  weapon 
system  acquisition  programs  would  use  the  HDR  to  identify  the  BCS  for  the 
new  weapon  system  under  development.  The  BCS  would  be  either  a  currently 
operational  weapon  system,  or  a  composite  system  composed  of  equipment  from 
two  or  more  currently  operational  systems.  Once  the  BCS  is  identified  based 
on  design  characteristics,  users  would  selectively  retrieve  R&M  and  support 
cost  information  from  the  HDR  to  serve  as  baseline  of  departure  for  the  new 
weapon  system. 

The  BCS  would  first  be  established  at  the  top  system  level,  then  at 
the  major  subsystem  levels,  and  finally  at  the  component  levels,  as  appro¬ 
priate.  A  most  convenient  and  useful  feature  would  be  to  enable  users  to 
retrieve  selected  BCS  information  from  the  HDR  in  LSAR  format  for  each 
desired  level  of  indenture.  Establishing  the  BCS  in  LSAR  format  would 
greatly  assist  the  government  in  establishing  system  level  availability  and 
R&M  requirements.  It  would  be  enormously  helpful  to  industry  for  allocating 
system  level  requirements  to  major  subsystems  and  lower  indenture  levels. 
Finally,  it  would  greatly  reduce  the  time  and  cost  required  to  accomplish 
trade  studies  and  analyses  for  obtaining  predictions  at  all  levels  in  the 
LSA/LSAR  process.  In  addition  to  achieving  substantial  time  and  cost  savings 
such  a  BCS  capability  would  greatly  enhance  the  effectiveness  of  the  ILS 
activity  throughout  the  system  acquisition  process. 

Achieving  the  capability  to  transform  field  data  into  comparable  LSAR 
data,  and  vice-versa,  is  the  key  to  creating  a  truly  closed-loop  UDB  system. 
This  capability  will  be  totally  achieved  only  if  a  mechanism  is  developed 
to  resolve  the  basic  incompatibilities  between  field  data  collection  systems 
and  the  LSA/LSAR  system  requirements.  The  UDB  achieves  this  by  a  set  of 
transformation  tables. 


Objective  4  -  When  the  user  retrieves  the  BCS  information  on  tape  from 
the  HDR  in  LSAR  form  and  content,  the  automated  LSAR  (ALSAR)  system  of  the 
UDB  will  enable  the  user  to  load  the  BCS.  The  BCS  would  be  used  to  support 
the  LSA  activity  for  the  new  weapon  system  development  program.  The  results 
of  the  LSA  would  be  recorded  in  the  LSAR  for  the  new  weapon  system.  The 
ALSAR  will  provide  a  cross-reference  between  the  BCS  and  the  new  weapon  system 
LSAR  at  each  level  of  indenture,  as  applicable.  This  feature  provides  a  con¬ 
venient  audit  trail  for  future  use. 

Since  the  detailed  LSA/LSAR  must  be  accomplished  by  industry,  the  ALSAR 
will  provide  on-line  and  batch  features  to  enhance  systems  engineering 
integration  throughout  the  design,  development,  and  production  phases  of  the 
new  weapon  system  acquisition  process.  The  LSA/LSAR  would  be  accomplished  at 
the  system  and  major  subsystem  levels  early  in  the  design/development  process. 
As  the  preliminary  and  detailed  design  is  expanded  to  lower  indenture  levels, 
the  LSA/LSAR  expands  accordingly. 

The  ALSAR  provides  the  mechanism  to  create,  manage,  and  utilize  a 
common,  consistent  LSAR  database  for  the  new  weapon  system  to  the  lowest 
reparable  level,  and  for  all  ILS  elements.  The  ALSAR  will  machine  generate 
standard  output  reports  that  satisfy  most  of  the  ILS  related  requirements 
associated  with  new  weapon  system  acquisition  programs.  This  automated 
feature  will  result  in  significant  cost  savings  in  report  preparation  and 
will  enhance  consistency  and  cost-effectiveness  in  planning  and  developing 
the  required  ILS  elements. 

It  is  envisioned  that  all  required,  allocated,  and  predicted  values  for 
the  new  weapon  system  LSAR  would  be  recorded  in  the  ALSAR  by  the  end  of  the 
full-scale  development  phase.  To  be  sure,  however,  the  ALSAR  would  continue 
to  be  used  throughout  the  production  phase  to  reflect  design  modifications 
and  assist  in  the  development  of  ILS  elements.  Furthermore,  the  ALSAR  would 
continue  to  be  used  during  OT&E  and  O&S ,  but  this  will  be  discussed  later. 

Objective  5  -  Standard  models  are  available  to  assist  in  accomplishing 
LSA  during  the  design  and  development  of  new  weapon  systems.  The  Network 
Repair  Level  Analysis  (NRLA)  Model  and  the  Logistics  Composite  Model  (LCOM) 
are  examples  of  these  important  tools.  The  UDB  should  be  designed  to  provide 


an  interface  mechanism  between  ALSAR  and  these  standard  models. 


In  Figure  1  this  capability  is  shown  as  Data  Generating  Technology. 

While  the  current  UDB  has  addressed  this  area,  there  is  tremendous  potential 
for  future  development  to  improve  and  enhance  this  capability.  An  important 
example  is  the  interface  between  the  HDR  and  ALSAR  with  computer-aided 
design  and  computer-aided  manufacturing  (CAD/CAM) . 

Objective  6  -  The  ALSAR  will  provide  the  capability  to  record  allocated, 
predicted,  and  measured  values  for  parameters  required  to  determine  the 
operational  suitability  and  effectiveness  of  the  new  weapon  system.  Prior 
to  OT&E  the  ALSAR  will  contain  allocated  and  predicted  values  for  the  new 
weapon  system  LSAR.  When  the  weapon  system  moves  into  the  OT&E  phase, 
measured  values  based  on  test  results  may  be  entered  using  the  on-line  or 
batch  system  of  the  ALSAR. 

This  ALSAR  feature  will  enable  the  government  and  contractors  to 
compare  requirements,  allocations,  predictions,  and  measured  results  in  a 
consistent  and  directly  comparable  manner.  To  the  extent  desired  and 
applicable,  comparison  with  the  BCS  could  also  be  achieved.  This  capability 
will  permit  early  identification  of  specific  problem  areas  and  permit 
problem  resolution  on  a  management-by-exception  basis.  This  process  will 
permit  early  verification  of  LSAR  in  areas  where  no  problem  areas  exist. 

Objective  7  -  During  the  early  O&S  phase  the  existing  field  data 
collection  and  reporting  systems  (MDCS,  D056,  VAMOSC)  will  be  used  to  vali¬ 
date  the  new  weapon  system  LSAR.  On  the  right  side  of  Figure  1,  a 
dashed-arrow  is  shown  that  implies  that  measured  values  for  validation  of 
the  new  weapon  system  LSAR  are  provided  directly  from  the  Field  Data 
Collection  Systems.  Although  this  is  not  totally  possible  due  to  the 
incompatibility  between  the  LSAR  and  the  field  data  systems,  as  was  mentioned 
in  the  discussion  of  the  BCS  under  Objective  3  above,  the  UDB  Transformation 
Tables  make  it  possible  to  some  degree. 

At  the  beginning  of  the  new  weapon  system  program  a  BCS  will  be  created 
and  loaded  into  the  ALSAR.  When  this  new  weapon  system  eventually  moves 
into  the  early  O&S  phase,  the  UDB  Transformation  Tables  will  be  used  to 


process  the  field  data  collected  on  the  newly  fielded  weapon  system. 

Instead  of  creating  a  BCS,  however,  the  output  at  this  point  will  reflect 
measured  values  for  appropriate  LSAR  parameters  of  the  newly  fielded  weapon 
system.  When  this  output  is  loaded  into  the  ALSAR,  the  measured  values 
derived  from  field  data  may  be  used  to  validate  the  LSAR  for  the  newly  fielded 
weapon  system. 

When  the  newly  fielded  weapon  system  LSAR  is  validated,  this  LSAR 
record  will  be  loaded  in  the  HDR  for  use  by  future  weapon  system  development 
programs.  This  is  shown  in  Figure  1  by  the  arrow  leading  from  the  validated 
LSAR  (Objective  7)  to  the  block  in  the  HDR  titled  "Systems  with  Validated 
LSAR."  Selected  portions  of  the  LSAR  may  be  stored  on  disk,  while  other 
portions  may  be  stored  on  magnetic  tape.  When  this  newly  fielded  weapon 
system,  or  any  portion  thereof,  is  used  as  the  BCS  for  a  future  weapon  system, 
a  complete  and  validated  LSAR  will  be  available  for  the  BCS.  As  the  HDR  is 
increasingly  populated  with  weapon  systems  for  which  a  Validated  LSAR  is 
available,  the  full  potential  value  of  the  closed-loop  UDB  system  will  be 
realized. 

Objective  8  -  Another  important  function  of  the  automated  HDR  will  be  to 
provide  trend  data  for  selected  R&M  and  support  cost  parameters.  This  is 
shown  in  Figure  1  as  product  performance  measurement  and  feedback  to  those 
responsible  for  continuing  development  (modifications),  operation  and  support 
of  a  weapon  system. 

Again,  the  capability  to  accomplish  this  function  totally  will  be 
dependent  on  the  mechanisms  discussed  earlier  to  create  the  BCS  and  validate 
the  LSAR  for  a  new  weapon  system.  As  shown  in  Figure  1,  the  Field  Data 
Collection  Systems  would  supply  information  for  currently  operational  systems; 
both  those  with  and  without  the  LSAR.  The  UDB  would  process  these  field  data 
and  calculate  and  capture  trend  data  as  a  function  of  selected  LSAR  parameters 
over  time/utilization.  These  trend  data  would  be  available  to  users  via 
on-line  command  and  displayed  on  CRT  terminal  screens  or  hard  copy  printout 
as  shown  by  Objective  8  in  Figure  1. 

The  rationale  for  utilizing  the  same  mechanisms  to  create  the  BCS,  vali¬ 
date  the  new  weapon  system  LSAR,  and  supply  trend  data  for  the  new  weapon 


system  during  the  O&S  phase  is  straightforward.  The  R&M  and  support  cost 
parameters  of  interest  should  and  do  remain  applicable  throughout  the  life 
cycle  of  a  weapon  system.  In  the  beginning  the  baseline  values  au- 
established,  followed  by  requirements  and  allocated  values.  Next  the  pre¬ 
dicted  values  are  established  during  design,  development,  and  production. 
In  the  OT&E  phase,  test  results  produce  measured  values  to  verify  the 
predictions  and  identify  problem  areas.  Finally,  the  field  data  collected 
in  the  O&S  phase  supplies  measured  values  to  validate  the  parameters  of 
interest.  These  validated  parameter  values  are  then  stored  in  the  HDR  and 
used  as  the  BCS  for  future  weapon  system  acquisition  programs,  as  appli¬ 
cable.  Using  the  same  mechanisms  to  accomplish  these  functions  is  both 
practical  and  necessary  to  facilitate  a  consistent,  compatible  closed-loop 
UDB  system. 


Objective  4'  -  A  vitally  important  concept  of  the  UDB  is  that  the  LSAR 
for  a  given  weapon  system  will  be  maintained  throughout  its  life  cycle. 
During  the  design,  development,  and  production  phases,  the  ALSAR  captures 
design  information  as  part  of  the  overall  LSAR  for  a  new  weapon  system.  As 
the  weapon  system  moves  into  OT&E  and  O&S,  the  measured  values  are  used  to 
verify  and  validate  the  LSAR  as  a  function  of  its  design  characteristics, 
concept  of  employment,  and  concept  of  maintenance. 

Figure  1  shows  that  those  responsible  for  developing  and  supporting 
a  new  weapon  system  would  continue  to  utilize  the  ALSAR  to  maintain  the 
new  weapon  system  LSAR  throughout  the  O&S  phase.  During  OT&E  and/or 
early  O&S,  design-related  problems  may  be  identified  that  require  modifica¬ 
tions  to  the  weapon  system.  When  this  occurs,  LSA  will  be  reaccomplished, 
as  approprl  i*e,  and  the  LSAR  will  be  updated  to  reflect  the  modified  design 
configuration.  Similarly,  if  and  when  changes  to  the  operational  and/or 
maintenance  concepts  for  the  weapon  system  are  eminent,  the  LSA/LSAR  will 
be  updated  to  reflect  these  changes  whether  or  not  design  modifications  were 
also  made. 


Objective  7’  -  After  modifications  are  incorporated  in  the  weapon  system 
the  ALSAR  will  again  be  used  in  conjunction  with  the  HDR  to  validate  the 


updated  LSAR.  This  step  would  also  be  accomplished  if  only  a  change  to  the 
operational  and/or  maintenance  concept  was  made.  Once  validated,  the  modi¬ 
fied  LSAR  would  be  stored  in  the  HDR  for  use  on  future  programs.  Trend  data 
on  R&M  and  support  cost  parameters  would  be  provided  for  the  modified  weapon 
system  on  a  continuing  basis,  as  appropriate. 

PROTOTYPE  UDB  APPROACH 

Conceptually,  the  UDB  could  be  used  to  support  many  types  of  DOD 
weapon  systems  and  equipment.  The  UDB  development  effort  was  limited  to  Air 
Force  requirements  for  aircraft  weapon  systems.  Figure  2  portrays  a  total 
aircraft  weapon  system  and  how  the  UDB  would  be  used  by  the  Air  Force  and 
contractors  throughout  the  acquisition  process. 
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INITIAL  PLAN 


As  discussed  earlier,  the  ALSAR  and  HDR  are  the  most  important  features 
of  the  closed-loop  UDB  concept.  Given  these  features,  the  data  generating 
technology  would  then  be  extremely  useful  in  accomplishing  LSA.  The  initial 
plan  for  the  UDB  effort  was  to  focus  primary  attention  on  the  HDR  and  data 
generating  technology,  and  to  use  the  DARCOM  ADP/LSAR  system  to  satisfy  the 
requirements  of  ALSAR.  A  detailed  study  of  the  DARCOM  system,  however, 
revealed  that  it  could  not  accommodate  the  UDB  objectives  for  the  ALSAR. 
Because  the  ALSAR  is  vitally  important  to  the  viability  and  utility  of  the 
overall  UDB,  primary  emphasis  was  shifted  to  development  of  this  fully  auto¬ 
mated  LSAR  system,  with  secondary  emphasis  on  the  HDR. 

UDB  FEATURES 

Figure  3  shows  in  bold-lined  boxes  the  two  major  features  of  the 
UDB  system;  the  ALSAR  and  the  Aircraft  Characteristics  Data  File  (ACDF) . 

These  features  were  developed  so  as  to  be  consistent  and  compatible  with  the 
UDB  system  objectives  discussed  earlier  in  Figure  1  and  shown  in  Figure  3. 

A  discussion  follows  as  to  the  degree  to  which  these  objectives  were  satis¬ 
fied  in  the  UDB  development  effort. 

Objective  1  -  The  ACDF  represents  the  HDR  for  currently  operational  air¬ 
craft  weapon  systems.  For  each  mission,  design,  and  series  (MDS) ,  the  ACDF 
will  contain  design  characteristics  data  and  processed  field  data  pertaining 
to  utilization,  R&M,  and  support  cost  parameters.  Initial  programs  have 
been  developed  to  process  data  from  D056E  and  VAMOSC  to  update  the  ACDF. 

Objective  2  -  The  automated  ACDF  provides  convenient  and  selective 
access  to  data  via  remote  on-line  CRT  terminal  screens.  This  capability  will 
assist  users  in  determining  the  BCS  for  a  new  weapon  system  and  selectively 
retrieving  BCS  information.  Using  the  same  capability,  users  may  retrieve 
information  from  the  ACDF  to  assist  in  determining  the  performance  of 
products  in  terms  of  R&M  and  support  cost  parameters. 
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Objective  3  -  The  transformation  tables  necessary  to  relate  field  data 
to  LSAR  terms  have  been  developed.  As  discussed  earlier,  this  is  a  very 
important  and  needed  capability;  first,  to  permit  establishment  of  a  BCS/LSAR 
and  second,  to  permit  validation  of  the  new  weapon  system  LSAR  using  existing 
field  data  collection  systems.  Development  of  this  capability  should  be 
accomplished  in  future  UDB  efforts. 

Users  must  manually  create  a  BCS  record  using  data  elements  and  values 
currently  retrievable  from  the  ACDF.  Using  the  BCS  data  retrieved  from  the 
ACDF,  users  may  utilize  the  f ield-to-LSAR  transformation  tables  for  con¬ 
structing  manually  BCS  data  that  could  be  loaded  in  ALSAR. 

Objectives  4-7  -  The  ALSAR  system  has  been  fully  developed  to  satisfy 
Air  Force  requirements.  A  BCS  may  be  loaded  into  the  ALSAR  and  cross- 
referenced  to  the  new  weapon  system  LSAR.  The  system  is  fully  automated  to 
assist  in  systems  engineering  integration  and  to  create,  manage,  and 
utilize  a  common,  consistent  record  for  all  ILS  elements.  ALSAR  programs 
are  available  to  create  outputs  from  the  LSAR  that  may  be  batch  loaded  as 
input  to  standard  logistics  models.  The  ALSAR  has  an  extensive  output 
summary  report  capability  in  accordance  with  standard  Data  Item  Descriptions 
(DID)  typically  required  in  Air  Force  programs. 

The  ALSAR  has  provisions  for  recording  measured  values  for  R&M  para¬ 
meters  required  to  be  tested  during  OT&E.  This  provision  may  also  be  used 
to  enter  measured  values  to  validate  the  LSAR  during  the  O&S  phase.  As 
discussed  under  Objective  3,  however,  the  ACDF  capability  to  process  field 
data  so  as  to  machine  output  the  required  LSAR  measured  values  has  not  yet 
been  developed. 

Objective  8  -  The  same  ACDF  programs  used  for  Objective  2  may  be  used 
to  track  the  continuing  performance  of  operational  weapon  systems.  The 
ACDF  presents  average  values  for  numerous  R&M  and  support  cost  parameters. 

No  trend  data  capability  is  provided  in  the  prototype  ACDF,  but  it  is 
expected  that  future  UDB  efforts  will  address  this  need. 


As  d  iscnssed  in  the  previous  sections,  the  AI.SAK  is  a  vitally  important 
part  of  the  UDB.  Specifically,  Lhe  AI.SAK  is  needed  to  sat  isly  Objectives  ), 
4,  6,  and  7  shown  in  Figure  I  and  discussed  in  Section  II.  The  AI.SAK  system 
discussed  in  this  section  has  been  fully  developed  and  partially  tested, 
using  H1I-60  helicopter  data.  Since  December  1982,  the  system  has  been 
successfully  used  in  a  production  mode  to  support  Lhe  Defensive  Avionics 
portion  of  the  B-1B  Strategic  Bomber  Program.  As  this  program  progresses, 
the  AI.SAR  system  features  will  be  fully  validated  for  operational  use  on 
other  programs. 

BASK  I.  INK 

The  DARCOMP  750-lb  data  elements,  data  definitions,  and  data  sheets/ 
records  were  used  as  the  baseline  for  the  AI.SAR  system.  To  the  extent 
practical,  consistent  with  Air  Force  requirements,  compatibility  with  the 
DARCOM  baseline  was  maintained.  Substantive  additions  to  the  baseline  were 
necessary,  however,  in  order  to  develop  a  fully  automated  system  that  would 
satisfy  Air  Force  and  DOI)  requirements,  and  provide  many  useful  and  cost¬ 
saving  features  for  Industry  and  (lovernment  users.  Since  the  AI.SAK  is  a 
fully  automated  database  system,  none  of  the  DARCOM  ADP/I.SAR  software  or 
programs  are  used. 

DOCUMKNTAT I ON 


The  AI.SAK  system  has  been  fully  documented  and  delivered  to  the  Air 
Force.  Ln  Table  I  the  individual  documents  associated  with  the  AI.SAK  are 
list  ed  . 


TABLE  1.  ALSAR  DOCUMENTATION 


Document 


Purpose 


Data  Sheets 


Data  input  sheets  used  by  ALSAR 


Data  Element  Descriptions 


For  data  elements  on  each  data 
sheet 


Data  Entry  Instructions 


ALSAR  Users  Guide 


Access  and  Security 
Manual 

Maintenance  and  Update 
Manual 

Software  Documentation 


For  entering  information  about 
each  data  element  on  each  data 
sheet 

For  using  each  feature  of  the 
automated  system 

On-line  procedures  to  control 
database  security 

Instructions  for  ADP  maintenance 
and  update 

Complete  programming  documen¬ 
tation  for  ALSAR  system 


Data  Sheets 

The  ALSAR  input  data  sheets  A  through  J  are  listed  in  Figure  4  and  in¬ 
cluded  in  Appendix  A.  Figure  4  is  actually  a  CRT  menu  screen  of  the  on-line 
ALSAR  system.  These  data  sheets  contain  all  of  the  data  elements  in  the 
ALSAR  system.  The  on-line  CRT  screens  used  to  input  data  are  designed  in  a 
manner  consistent  with  the  card  record  layouts  on  each  sheet.  A  data  sheet 
status  output  report  may  be  machine  produced,  on  command,  in  the  format  and 
content  identical  to  each  input  data  sheet. 

In  Appendix  A  the  reader  will  notice  that  the  basic  80-column  card 
format  is  used  for  the  data  sheets.  This  was  the  result  of  an  Air  Force 
requirement  that  ALSAR  be  developed  so  as  to  retain  consistency  with  the 
DARCOM  ADP/LSAR  system  wherever  possible.  Since  the  DARCOM  system  is 
basically  a  sequential  file  batch  processing  scheme,  it  requires  the 
80-column  card  format  along  with  duplication  of  key  information  on  each 
card.  The  fully  automated  ALSAR  system  would  permit  more  simplified, 
efficient,  and  user  friendly  data  sheets.  For  example.  Data  Sheet  A 
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DPR  LSA0M-01,  MENU  SCREEN  1,  AFM01D ,  AFHOIU 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  AS  OF  xxxxxxx  xx/xx/xx 

MENU  1 

SHEET 

A  OPERATIONS  AND  MAINTENANCE  REQUIREMENTS 

B  ITEM  RELIABILITY(R)  AND  MAINTAINABILITY (M)  CHARACTERISTICS 

C  TASK  ANALYSIS  SUMMARY 

~  D  MAINTENANCE  AND  OPERATOR  TASK  ANALYSIS 

E  SUPPORT  AND  TEST  EQUIPMENT  OR  TRAINING  MATERIAL 

DESCRIPTION  AND  JUSTIFICATION 
F  FACILITY  DESCRIPTION  AND  JUSTIFICATION 

G  SKILL  EVALUATION  AND  JUSTIFICATION 

H  SUPPLY  SUPPORT  REQUIREMENTS 

I  AUTOMATIC  TESTING  EQUIPMENT/TEST  PROGRAM  SET  DESCRIPTION 

J  TRANSPORTABILITY  ENGINEERING  CHARACTERISTICS 


FOR  A  LIST  OF  REPORT  REQUESTS  TYPE  RPTMENU 


L‘  >'V 

k* 

L#£2 


DATA  SHEET  MENU  SCREEN 
FIGURE  4 

could  be  changed  to  display  the  Logistics  Support  Analysis  Control  Number 
(LSACN)  only  once,  rather  than  displaying  it  on  each  card.  In  future  UDB 
development  efforts,  consideration  will  be  given  to  designing  the  data 
sheets  in  a  manner  consistent  with  the  fully  automated  ALSAR  system. 

Initial  user  reaction  to  the  ALSAR  data  sheets  may  be  negative  because 
of  the  redundant  key  data  elements  appearing  on  all  sheets  and  the  data 
elements  added  to  the  A,  B,  E,  and  H  Sheets  appear  to  increase  the  user 
workload.  In  fact,  the  fully  automated  ALSAR  system  eliminates  the  need 
for  users  to  enter  redundant  data.  The  new  data  elements  added  to  the  data 
sheets  enable  the  ALSAR  to  satisfy  multiple  Air  Force  and  DOD  requirements 
and  to  facilitate  automated  output  reporting  that  will  result  in  significant 
time  and  cost  savings. 

Data  Entry  Instructions 

All  of  the  data  elements  on  the  ALSAR  data  sheets  are  defined  in  the 
Data  Element  Descriptions  (DED)  document.  The  Data  Entry  Instructions  (DEI) 
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document  tells  the  user  how  to  fill  out  each  data  sheet.  Since  the  ALSAR  is 
fully  automated  for  on-line  data  entry  and  update,  it  is  not  mandatory  that 
users  manually  fill  out  data  sheets.  In  any  case,  users  should  be  thoroughly 
familiar  with  the  ALSAR  procedures  and  conventions  regarding  data  entry  in 
order  to  capitalize  on  the  many  useful  and  time-saving  features  of  the  fully 
automated  system. 

ALSAR  Users  Guide 

While  the  DEI  instructs  the  user  in  how  and  where  to  enter  the  results 
of  the  LSA  on  each  data  sheet,  this  guide  describes  the  on-line  and  batch 
functions  of  the  ALSAR  system  and  provides  instruction  for  operation  and 
use  of  the  on-line  system.  This  includes  procedures  for  retrieving  CRT 
terminal  screens  to  enter,  update,  and  display  information  in  the  database 
relating  to  any  data  sheet  and  also  for  requesting  hard  copy  or  tape  output 
summary  products  and  reports  available  from  the  ALSAR  system. 

Access  and  Security  Manual 

This  document  provides  instructions  for  establishing  and  controlling 
the  ALSAR  database  accessibility  and  security.  While  this  on-line  feature 
is  easy  to  use,  it  provides  great  flexibility  in  controlling  the  access  and 
update  capability  of  functional  area  users. 

Maintenance  and  Update  Manual 

This  document  provides  information  of  interest  only  to  computer  center 
personnel  responsible  for  the  maintenance  and  update  of  the  ALSAR  system. 

This  document,  along  with  the  complete  software  documentation  package,  should 
be  sufficient  to  permit  installation,  operation,  and  maintenance  of  the  ALSAR 
at  a  computer  facility  that  has  compatible  hardware  and  system  software. 

SYSTEM  DESIGN 

Figure  5  shows  the  basic  design  approach  for  the  fully  automated  ALSAR 
system.  Notice  that  the  ALSAR  utilizes  the  Integrated  Database  Management 


System  (IDMS)  developed  by  Cullinet  Corporation.  The  IDMS  components  used 
are  the  Integrated  Data  Dictionary,  Data  Dictionary  Reporter,  On-Line  Query, 
Data  Communications  Monitor,  and  Database  Manager.  Clemson  University 
developed  a  general  purpose  software  package  for  creating  CRT  terminal 
screens  and  performing  full  screen  edits.  This  package  is  provided  with  the 
ALSAR. 

All  on-line  application  programs  are  designed  to  run  with  the  IDMS  Data 
Communications  Monitor,  an  efficient  and  multi-tasking  communications  monitor 
This  enables  excellent  response  for  larger  multi-terminal  real-time  systems 
and  also  provides  for  automatic  journaling  of  all  transactions. 


ALSAR  SYSTEM  DESIGN 
FIGURE  5 


There  are  approximately  300  application  programs  written  to  accomplish 
the  on-line  and  batch  functions  of  the  ALSAR.  They  are  written  in  ANSI  COBOL 
with  embedded  IDMS  verbs.  Each  program  was  designed  with  functional 
modularity  in  order  to  allow  for  ease  of  maintenance  and  adaptation  to  new 
environments.  The  application  system  contains  a  complete  security  subsystem 
that  can  be  used  to  control  access  to  and  modification  of  data  by  users. 

This  security  feature  also  provides  a  complete  audit  trail  ol  changes  made 


during  on-line  operations. 

GENERAL  FEATURES 

There  are  several  important  features  of  the  ALSAR  that  relate  to  the 
overall  LSA  process  and  specific  DOD  requirements. 

LSA  CONTROL  NUMBER  (LSACN) 

The  LSACN  is  a  key  data  element  in  the  ALSAR  system  and  is  comprised  of 
the  Work  Unit  Code  (WUC)  and  the  Work  Breakdown  Structure  (WBS) .  This 
approach  accomplishes  several  important  objectives  addressed  in  DODD  5000.39 
and  MIL-STD-1388.  First,  it  permits  convenient  and  effective  management  of  a 
common,  consistent  database  of  information  necessary  to  support  all  ILS 
elements.  Second,  it  provides  an  effective  mechanism  to  relate  field  data  to 
LSAR  data  during  the  O&S  phase,  thus  facilitating  validation  of  the  LSAR  for 
a  weapon  system.  Third,  it  provides  an  inherent  cross-reference  between  WUC 
and  WBS  for  correlation  of  support  costs  to  acquisition  costs. 

The  ALSAR  does  not  depend  upon  the  LSACN  to  generate  provisioning 
technical  documentation,  as  does  the  DARCOM  system.  The  manner  in  which 
ALSAR  accomplishes  automatic  generation  of  provisioning  documentation  is 
discussed  later.  Since  this  approach  is  used,  the  ALSAR  assigns  LSACNs  only 
to  the  lowest  reparable  level  of  the  end  item.  Assignment  of  LSACNs  to 
non-reparable  items  is  not  required. 

PERFORMANCE  TRACKING 

The  Air  Force  typically  requires  that  the  performance  of  specified 
parameters  be  verified  in  OT&E  and  tracked  during  O&S.  In  order  to  achieve 
the  objectives  of  the  UDB,  specifically  Objectives  6  and  7  in  Figure  1  which 
address  this  Air  Force  requirement,  several  features  were  incorporated  into 
the  ALSAR  system. 

Additional  Data  Elements 

Numerous  data  elements  were  added  to  the  A  and  B  Data  Sheets,  as  shown 
in  Table  2.  With  these  additional  data  elements  the  required  or  allocated. 
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TABLE  2.  ALSAR  PERFORMANCE  TRACKING 


PIRfORNAMCE  PARAICTtl  VALUES 


riouxrid/ allocated  value 


predicted  value 


•CASURED  VALUE 


SYSTEM  LEVEL  CMLY 


•  MISS  ION  COMPLETION  SUCCESS  PROBABILITY 

•  AVAILABILITY : 

PIC.  FIC/M.  PIC/S.  PMC /MAS 
NNC,  HMC/N.  HMC/S.  MC/NAS 

pmc.  irr/ sortie 

•  BASE  LEVEL  MM/ PH:  SOYV  ORGANIZATIONAL  LEVEL  AMD  HfTERKDlATE  LEVEL 

SUPPORT  CEMTEAL 

SCMEDCUD  AMD  SPECIAL  IMSPECT10MS  (03  A  04) 

PREVENTIVE  MAIMTEMAMCE 
CORRECTIVE  NADrrDUMCt 
TOTAL  BASE  LEVEL  INC/N 

•  BABE  LEVEL:  BOTR  ORGANIZATIONAL  LEVEL  AMD  OTTEMDIA1Z  LEVEL 

mam  naivtouncz  m/m  to  repair  <nctr> 

MAXIMUM  ELAPSED  TOC  TO  BIPAI1 

•  DEPOT  NC/VM: 

PRDGRaMCD  DEPOT  NAlMTMAJCt 
anew  EM!  KPAU /OVERBAD. 

•  KISS IOH  BECOMPICURATIOM  TTJC : 


ANALYTICAL  OOVDITIOM  XVSPECTIOM 
mu*  SLAPS  ID  TOC 


■LAPSED  TOC 

NAnrrnANce  mt-mrm 

emu  mi 

aircum  mam~  norms 

•  VAULT  DETECTION/ ISOLATION  AO  FALSE  FAULT  DO)  I  CAT  I OM 

•  EEL  LABILITY : 

•CAM  TOC  BETWEEN  REMOVALS  (Mill) 

•CAM  TIME  BETWEEN  COEllCTTVt  NADTOUNCt  (MTW) 
UCERDPT  MALPOMCTIOMS  (TYPE  1  TOM) 

DDUCED  MALPOMCTIOMS  (TYPE  2  KTVO 
MO  DEPICT  (TYPE  A  MTW) 

P  SEVEN  LIVE  (SMEDULED  REMOVALS)  (KTBM) 

•cam  me  invEZM  maintenance  actions  orimi 

RATIO  OP  MADrmUMa  ACTIONS  to  NAlNTnANCE  EVENTS 
•CAM  TOC  to  ripah 


_ _ _ SYSTEM  LCftt  ONLY _ 

•  ESTIMATED  AMD  ACTUAL  OMIT  (PLY  AM  AT)  COST  -  SOT1  BCUULIMC 


•  FAULT  DETECT ION /ISOLATION  AMD  FALSE  FAULT  INDICATION 

•  RELIABILITY ; 

•CAN  TDK  RETVEF*  REMOVALS  (MTO1) 

•CAN  TOC  SEYVEOl  CCCUCTIVC  MAETT  (KTBM) 
maUMT  MALFUNCTIONS  (TYPE  1  KIBM) 

WDOCTD  MALFUNCTIONS  (TTPE  2  KTSH) 

NO  DEFECT  (TTPE  6  KTBM) 

PEEVEirriVE  <  SCHEDULED  RZ3CVALS)  KTBH 

•CAM  TOC  BETWEEN  MAINTENANCE  ACTIONS  (MT1MA) 

•atio  of  haintemancx  actions  to  maintenance  events 
•CAM  TOC  TO  REPAIR 

•  BASE  LEVEL  MH/Pl  -  BOTH  ORGANIZATIONAL  (OM-EQUIP)  AMD 

OmCMDLATt  (OFF- EQUIP)  LEVELS 
FgVPfim  NAlNTEMAMCt 

CORRECTIVE  MAINTENANCE 
TOTAL  BASE  LEVEL  NC/Fl 

•  BASE  LEVEL  (CAM  MAINTENANCE  M/M 

PBEVEMllVi 

COUECTTVE 

•  DEPOT  LEVEL  MC/FN  AND  tCAM  TIKE  TO  REPAIR  (Km) 

•  WOK  KIT  COM  BY  TASR  COM:  (TASK  SUIMARY ) 

TASK  FREQUENCY 
IASI  TOC  (ELAPSED) 

TASK  HAJCOU1S 
NO.  Of  MM/TASK 


•  scs  sapporr  cost  in  acdf 

•  NXU  ST  STEM  SUPPOKT  OOST  DATA  P10YIDED/ UPDATED  Oi  ACDF 


•  ESTIMATED  AND  ACTUAL  ACTUAL  041  COST 

•  INITIAL  SUPPORT  WU1PIT1  COST  -  DOTH  001  DM  AND 
PECULIAR  S.I. 

•  SPARES  COST  -  BOTS  INITIAL  AND  KPUMISBCirr  SPARES 

•  BASE  MATERIAL  COST/Y1 

•  BABE  POL  COfT/Yl 

•  TIOWTCAL  PUBLICATIOK  COST  A  QUANTITY 

•  TRAIN  INC  COST  -  PEBBONMIL  A  MATKIAL/  BOPIWCNT  » 

•  mnan  or  people  trained  a  wet  skills  kequiked  u 

•  PlDClAltCD  knot  mahttenanci  COST/TR 

•  coieoMprr  upaik/ovekaul  depot  cdst/ti 

•  INITIAL  DEPOT  SUPPOKT  EQUIPMENT  COST 

•  FACILITIES  OOST  -  BOTH  FOR  RASE  LEVEL  A  DEPOT  LEVEL 


BOTR  AT  BASE  A  DEPOT 
LEVELS 


predicted,  and  measured  values  of  performance  parameters  may  be  recorded  and 
tracked  throughout  the  life  cycle  of  a  system.  These  parameters  may  be 
measured  at  the  system,  major  subsystem,  and  component  levels  if  desired. 

At  the  system  level,  data  elements  were  also  added  to  the  A  Sheet  to 
capture  predicted  and  measured  values  of  selected  cost  parameters.  The 
predicted  values  would  be  entered  early  in  the  development  phase,  and  the 
measured  values  during  the  production  phase.  This  information  would  be 
valuable  in  the  future  for  establishing  cost  estimating  relationships  and 
improving  predictions  on  future  weapon  system  programs.  At  the  subsystem  and 
component  levels,  the  UDB  will  use  the  ACDF  to  capture  selected  VAMOSC  data 
to  track  cost  parameters  for  a  weapon  system. 

Task  Codes 

The  ALSAR  uses  the  following  approach  to  assign  maintenance  task  codes 
for  Air  Force  applications.  The  fifth  and  eighth  positions  of  the  Task  Code 
use  unique  task  identifiers,  as  applicable,  to  facilitate  comparability 
between  LSAR  and  field  data  systems.  All  other  positions  of  the  Task  Code 
are  assigned  in  accordance  with  MIL-STD-1388-2A.  The  manner  in  which  ALSAR 
utilizes  the  WUC  and  Task  Code  is  crucial  to  verifying  the  LSAR  for  a 
weapon  system  after  fielding. 

How  Malfunction  Codes  and  Work  Cent e_r 

The  ALSAR  D  Sheet  incorporates  a  How  Malfunctioned  (How  Mai)  code 
for  further  relating  the  LSAR  data  to  field  data.  The  ALSAR  also  uses  an 
automated  scheme  to  relate  the  Skill  Specialty  Code  (SSC)  primarily  respon¬ 
sible  for  a  task  to  a  performing  work  center,  thus  providing  another 
necessary  link  for  comparing  LSAR  data  to  field  data. 

Maintenance  Events/Maintenance  Actions 

There  are  other  features  incorporated  in  the  ALSAR  system  to  bridge  the 
inherent  gap  between  LSAR  and  field  data.  For  example,  the  procedures  for 
documenting  maintenance  requirements  on  the  B  Sheet  result  in  automatic 
identification  of  maintenance  actions  that  comprise  a  maintenance  event.  All 


of  the  above  features,  plus  some  provided  but  not  mentioned  here,  are  needed 
to  effectively  utilize  field  data  to  update  and  verify  the  LSAR,  thus  making 
the  ALSAR  a  useful  tool  throughout  the  life  cycle  of  a  weapon  system. 

ALTERNATE  ACTION 

Each  ALSAR  data  sheet  has  a  data  field  to  record  an  Alternate  Action 
Code  (A,  B,  C,  etc.).  When  an  LSA/LSAR  is  accomplished  for  multiple  design 
concepts,  the  Alternate  Action  Code  is  used  to  partition  the  data  for  each 
separate  concept.  The  provision  is  useful  in  trade-off  studies  and  provides 
a  permanent  record,  if  desired,  for  candidate  approaches  considered.  Since 
the  Alternate  Action  Code  is  a  key  parameter,  the  alternate  chosen  as  the 
final  design  is  designated  as  Alternate  Action  A.  In  this  way  the  primary 
LSA/LSAR  record  for  an  entire  end  item  will  be  partitioned  under  a  single 
Alternate  Action  Code.  Alternate  Action  Code  Z  is  used  to  designate  the 
BCS  for  the  new  weapon  system  within  the  UDB,  thereby  providing  a  fully 
automated  BCS  conveniently  cross-referenced  to  the  new  weapon  system  LSA/LSAR 

LSAR  REVISIONS 

The  specific  LSA/LSAR  requirements  of  any  given  program  will  determine 
the  extent  to  which  the  ALSAR  data  sheets  are  completed.  For  each  card  on 
each  data  sheet  required  by  a  given  acquisition  program,  users  may  determine 
the  specific  data  elements  that  must  be  filled  in  to  constitute  a  completed 
card.  Some  programs  may  require  all  data  elements  on  a  given  card,  while 
others  may  require  only  a  portion  of  the  card  to  be  filled  in.  The  point 
is  that  only  the  user  on  a  given  program  will  know  what  constitutes  a  com¬ 
pleted  card  and  data  sheet. 

The  Update  Code  (UC)  in  the  right-hand  column  of  each  card  (see  Appendix 
A)  will  be  used  to  indicate  whether  the  card  is  in-work  or  completed.  When 
the  user  changes  the  card  status  to  "completed,"  the  ALSAR  will  automatically 
record  and  track  subsequent  revisions  using  the  UC  and  date.  The  same  is 
true  for  a  completed  data  sheet.  This  provides  an  automated  capability  to 
assist  ILS  Managers  in  monitoring  the  progress  of  LSA/LSAR  activity  in  terms 
of  initial  completion  status,  as  well  as  the  revisions  made  to  completed 


work.  From  an  historical  perspective,  this  capability  will  provide  an  LSAR 
audit  trail  that  may  be  used  throughout  the  life  cycle  of  a  weapon  system. 
This  may  be  particularly  useful  when  tracking  the  performance  of  key  para¬ 
meters,  since  it  will  provide  a  date  benchmark  corresponding  to  equipment 
modifications  during  O&S. 

EFFICIENT  DATA  ENTRY 

As  mentioned  earlier,  the  ALSAR  data  sheets  were  patterned  after  the 
DARCOMP  750-16  formats.  As  a  result,  there  is  significant  redundancy  of  key 
data  elements  on  most  of  the  data  sheets.  The  fully  automated  ALSAR  has  been 
designed  to  eliminate  the  requirement  for  the  user  to  enter  redundant  data. 
Some  of  the  automated  features  incorporated  to  save  user  time  and  effort  are 
discussed  below. 

Key  Parameters 

The  ALSAR  database  is  structured  to  utilize  key  parameters  such  as  the 
LSACN,  Alternate  Action,  and  Manufacturers  Part  Number  (MPN) .  While  it  is 
necessary  to  specify  key  parameters  when  using  the  on-line  system,  the 
machine  will  automatically  enter  these  specified  parameter  values  on  multiple 
cards,  as  appropriate.  For  example,  it  is  not  necessary  to  enter  the  LSACN 
on  each  card  of  the  A,  B,  C,  Dl,  E,  F,  and  G  Sheets. 

Header  Information 

The  first  three  cards  of  the  A,  B,  and  C  Sheets  contain  identical 
header  information.  When  an  A  Sheet  is  completed  for  the  system  and  major 
subsystem  levels,  the  ALSAR  will  automatically  enter  the  B  Sheet  header 
information.  Similarly,  when  a  B  Sheet  is  completed  for  component  levels, 
the  C  Sheet  header  information  will  automatically  be  entered. 

When  information  describing  a  part  is  entered  on  the  B,  C,  or  Dl  Sheet, 
the  ALSAR  will  automatically  enter  selected  parts  information  in  the  Supply 
Support  (H  Sheet)  record  or  the  Support /Test  Equipment  (E  Sheet)  record,  as 
appropriate.  This  provision  not  only  saves  data  entry  time,  but  insures 


consistency  between  the  maintenance,  supply  support,  and  support  equipment 
records . 

Multiple  Applications 

The  first  time  a  Line  Replaceable  Unit  (LRU),  Shop  Replaceable  Unit 
(SRU) ,  or  repair  part  is  recorded  in  the  maintenance  record  (B,  C,  or  D1 
Sheet),  a  basic  Supply  Support  record  (HOI,  H02  and  H03  cards)  will  be 
established  for  that  part.  This  basic  record  will  not  be  repeated  even 
though  a  part  may  be  used  in  multiple  applications  in  an  end  item.  For  each 
individual  application  of  the  part,  only  the  application  significant  informa¬ 
tion  must  be  entered.  The  ALSAR  system  transfers  available  information  to 
the  basic  record  the  first  time  a  part  is  identified,  and  prompts  the  user 
to  complete  the  basic  and  application  significant  information.  For  sub¬ 
sequent  applications  of  that  part,  the  ALSAR  system  notifies  the  user  that 
only  application  significant  information  is  needed,  and  automatically 
aggregates  relevant  provisioning  information  for  the  part. 

The  same  process  is  used  for  support  and  test  equipment  on  the  E  Sheet. 
The  first  time  a  particular  piece  of  equipment  is  required  to  support  a 
maintenance  task,  the  machine  will  transfer  the  available  information  and 
prompt  the  user  to  complete  a  basic  E  Sheet.  When  subsequent  maintenance 
tasks  require  this  piece  of  equipment,  the  ALSAR  will  automatically  record 
these  requirements  by  maintenance  task  and  the  item  being  supported.  In  a 
similar  manner  the  ALSAR  permits  a  basic  record  for  each  Facility  (F  Sheet) 
and  Skill  (G  Sheet)  ,  and  automatically  records  each  individual  requirement 
for  this  logistics  resource. 

NARRATIVE  DATA 

The  narrative  cards  on  the  ALSAR  data  sheets  incorporate  a  card  letter 
and  sequence  line  number  (Seq.  No.)  provision  that  enables  virtually 
unlimited  space  for  narrative  information.  This  provision  will  enable  ILS 
Managers  to  further  integrate  and  support  the  efforts  of  those  responsible 
for  technical  manuals  through  the  ALSAR.  The  provision  is  required  to  enable 
the  ALSAR  to  produce  important  output  reports  such  as  the  Support  Equipment 
Recommendations  Document  (SERD) . 


ON-LINE  PROCESSING 


The  ALSAR  system  utilizes  on-line  CRT  terminal  screens  to  enter,  re¬ 
trieve,  and  update  information  in  the  LSAR  database.  In  addition,  all  of  the 
output  products  available  from  ALSAR  may  be  requested  using  the  on-line 
system.  The  ALSAR  Users  Guide  shown  in  Table  1  provides  the  detailed  infor¬ 
mation  for  operation  of  the  on-line  system. 


MENU  SCREENS 

Thirteen  menu  screens  are  provided  for  those  getting  acquainted  with 
the  system.  Figure  4  is  the  menu  screen  that  shows  all  of  the  ALSAR  data 
sheets.  Placing  an  X  by  one  of  the  data  sheets  will  cause  the  menu  for  that 
sheet  to  be  displayed.  For  example,  placing  an  X  by  the  A-Sheet  will  display 
the  A-Sheet  menu  screen  as  shown  in  Figure  6.  All  of  the  card  records  on  the 
A-Sheet  are  shown  in  Figure  6,  and  to  display  a  screen  for  a  particular  card 
record,  the  user  would  simply  place  an  X  by  the  desired  card. 
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DATA  ENTRY  SCREENS 


There  are  70  on-line  screens  to  enter,  retrieve,  and  update  information 
in  the  database.  Each  screen  consists  of  data  elements  for  one  or  more  card 
records  on  one  of  the  data  sheets  in  Appendix  A.  Figures  7  and  8  are  repre¬ 
sentative  examples  of  these  on-line  screens.  Figure  7  is  the  screen  for  the 
A05  and  A06  cards  of  the  A-Sheet,  and  Figure  8  is  for  the  B01 ,  B02 ,  and 
B03A  cards  of  the  B-Sheet.  Each  on-line  screen  may  be  called  by  simply 
entering  a  command  for  the  desired  card  along  with  the  required  parameters. 


DPR  LSA0A-03.  DATA  SHEET  A.  IRC  LEVEL, CN-EQUIP  MAINT  AP&03D  AFA03U 
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-28 


For  example,  entering  the  E01  command,  along  with  the  desired  LSACN  and 
Alternate  Action  will  retrieve  the  screen  shown  in  Figure  9;  this  screen 


OPR  LSAOE-Ol.  OITA  SHEET  E.  STE  OR  TRNG  MATERIAL  OESC  AND  JUST  -  AFE01D.  AFE01U' 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  AS  OP  xxxxxxxx  :oc/xx/xxi 
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also  contains  the  E02,  E03A,  and  E03B  cards.  When  the  screen  is  retrieved, 
the  LSACN  is  machine  entered  in  each  card,  as  indicated  by  the  X’s  in  the 
LSACN  fields. 


The  numbers  in  parentheses  after  each  data  element 
number  of  the  first  position  for  a  data  element  field, 
reduce  errors  when  data  are  being  entered  from  hard-copy 
screen  cursor  is  programmed  to  move  automatically  to  the 
data  field  to  simplify  and  expedite  data  entry. 


denote  the  column 
This  feature  will 
worksheets.  The 
next  unfilled 


ENTERING  DATA 

Once  a  screen  has  been  displayed,  the  user  may  complete  all  or  part 
of  the  data  elements,  as  desired.  Changes  or  corrections  may  be  made  on  the 
screen  prior  to  hitting  the  "ENTER"  key  on  the  terminal.  The  ENTER  key 
records  the  screen  display  on  the  ALSAR  database,  assuming  data  have  oeen 
entered  by  the  user. 


EDIT  CHECKS 


The  on-line  system  incorporates  edit  checks  for  selected  data  elements 


The  edits  performed  on  each  screen  are  described  in  the  ALSAR  Users  Guide, 
and  generally  consist  of  checks  for  required  presence,  alphanumeric 
characters,  field  size,  special  codes,  and  format.  When  the  user  attempts 
to  enter  data  that  do  not  pass  an  edit  check,  the  CRT  terminal  screen  will 
indicate  the  error  by  flashing  the  affected  data  element  field  and  will  not 
allow  any  of  the  data  on  the  screen  to  be  entered  in  the  database.  At  this 
point  the  user  has  two  options.  First,  the  user  may  correct  the  errant 
data  on  the  screen  and  then  enter  them  in  the  database.  Alternately,  the 
user  may  force  the  errant  data  to  be  entered  in  the  database.  This  is 
accomplished  by  using  the  Force  (F)  command  and  then  pushing  the  "ENTER" 
key.  The  F  command  would  be  used  when  it  is  not  convenient  or  possible  to 
determine  the  cause  of  an  error  immediately,  and  the  majority  of  the  data 
on  the  screen  are  correct. 

DATA  RETRIEVAL 

When  information  has  been  entered  on  the  database,  such  data  may  be 
retrieved  and  displayed  by  simply  calling  the  screen  for  the  card,  with 
appropriate  parameters,  on  which  the  data  were  entered.  When  errant  data 
were  forced,  the  ALSAR  system  will  display  the  errant  data  field  with  a 
series  of  question  marks  (???),  whether  retrieved  on-line  or  on  hard-copy 
printout . 

DATA  UPDATE 

Except  for  key  parameters  which  are  protected  fields,  any  informa¬ 
tion  in  the  ALSAR  database  may  be  updated  at  the  discretion  of  a  user. 

After  the  appropriate  on-line  screen  containing  the  information  of  interest 
is  retrieved,  the  UPDATE  (U)  command  would  be  used  to  activate  this  mode. 

At  this  point  the  user  may  make  any  desired  modifications  or  deletions  by 
simply  typing  over  the  existing  data  and  entering  the  updated  information 
in  the  database. 

When  an  update  is  accomplished  on  a  card  previously  coded  "COMPLETE" 
in  the  Update  Code  (UC) ,  the  ALSAR  will  automatically  record  the  update  as 
a  modification  to  the  LSAR.  The  purpose  and  value  of  this  feature  was 


discussed  earlier. 


GLOBAL  CHANGE  CAPABILITY 

At  times  it  may  be  necessary  to  change  key  parameter  values  (LSACN, 

MPN,  etc.)  previously  entered  in  the  database.  While  such  changes  are  not 
possible  using  the  UPDATE  command,  batch  programs  are  provided  to  accomplish 
changes  in  a  global  manner.  For  example,  if  an  LSACN  requires  a  change, 
this  program  will  replace  the  old  LSACN  with  the  new  LSACN  at  every  appro¬ 
priate  location  throughout  the  database. 

GENERIC  COPY  CAPABILITY 

When  an  LSA  has  been  accomplished  on  an  item  and  the  LSAR  entered  in 
the  database,  the  user  may  find  that  all  or  part  of  this  information  may 
be  applicable  to  another  item  for  which  LSA/LSAR  is  required.  The  ALSAR 
system  will,  on  user  command,  selectively  copy  all  or  part  of  the  database 
record  for  one  LSACN  to  another  LSACN,  whether  it  be  one  card  or  multiple 
data  sheets.  Once  the  desired  copy  function  has  been  accomplished,  the 
update  capability  would  be  used  to  make  corrections,  as  necessary,  to 
satisfy  unique  requirements  of  the  newly  created  LSACN  record. 

MAINTENANCE  AND  SUPPLY  SUPPORT  FILES 

Supply  support  requirements  are  basically  derived  from  maintenance 
requirements,  as  are  the  requirements  for  personnel,  support  equipment, 
training,  training  equipment,  facilities,  and  technical  manuals.  Maintenance 
requirements  are  derived  from  the  system  level  operational  and  support  con¬ 
cepts,  and  from  detailed  R&M  analyses  at  all  levels  of  hardware  indenture. 

The  ALSAR  svstem  incorporates  features  that,  in  essence,  take  the  main¬ 
tenance  requirements  documented  on  the  B,  C,  D,  and  D-l  Sheets  and  automat¬ 
ically  create  basic  records  of  other  support  requirements  on  appropriate 
data  sheets  (E,  F,  C  and  H) .  These  features  were  mentioned  earlier  in  the 
paragraph  addressing  efficient  data  entry  for  multiple  applications.  Using 
this  approach,  the  ALSAR  system  assures  consistency  and  compatibility 


between  the  maintenance  requirements  and  the  other  ILS  elements. 

Portions  of  the  B,  C,  and  D1  Sheets  are  used  to  drive  the  supply 
support  requirements  documented  on  the  H-Sheet.  The  C03  card  is  used  to 
establish  the  top-down  hardware  breakdown  in  accordance  with  engineering 
drawings  and  the  MPN  to  Next-Higher-Assembly  MPN  relationships.  Usifig  this 
information,  the  ALSAR  automatically  creates  H40  cards  from  which  the 
Provisioning  Parts  List  (PPL)  is  machine  produced.  Using  this  approach, 
the  ALSAR  eliminates  the  need  to  use  the  LSACN  to  produce  provisioning 
technical  documentation  as  required  by  DARCOM.  This  permits  the  LSACN  to 
be  assigned  only  to  the  reparable  level  using  the  WUC/WBS,  which  in  turn 
results  in  the  significant  advantages  discussed  earlier.  Non-reparable 
items  are  appropriately  accounted  for  and  documented  in  accordance  with 
standard  reporting  requirements. 

When  specific  LSA  requirements  for  a  given  acquisition  program  do  not 
logically  result  in  a  complete  top-down  breakdown  of  the  MPN  to  Next-Higher 
Assembly  MPN  relationship  for  the  total  system,  the  user  would  utilize  the 
ALSAR  on-line  system  to  enter  H40  cards  to  add  missing  parts,  as  applicable 
The  ALSAR  system  processing  will  notify  the  user  when  and  where  gaps  in 
the  PPL  exist. 

BATCH  PROCESSING 

INITIAL  BATCH  LOAD 

The  Initial  Batch  Load  can  be  used  for  initial  loading  of  the  data¬ 
base  or  for  subsequent  additions  of  new  records  if  the  key  information  is 
unique.  It  is  not  intended  for  update  or  editing  capability  for  existing 
data.  The  system  accepts  ALSAR  card  formatted  data  from  sequential  files. 
There  are  three  phases  to  the  load  process,  each  of  which  performs  edits  on 
the  input  data  and  produces  a  report.  These  reports  should  be  used  to 
guarantee  the  integrity  of  the  loaded  database. 


Phase  1 


In  this  phase  the  card  images  are  read,  edited  individually  while  flow 
assurance  editing  is  done,  and  finally,  the  narrative  data  are  separated 
from  the  rest  of  the  inputs.  The  first  report  that  is  produced  from  this 
phase  is  a  control  report  which  is  to  be  used  until  this  phase  is  com¬ 
pleted.  It  is  a  sequential  listing  assigning  a  control  number  for  future 
reference.  Next  an  edit  report  is  produced  detailing  which  fields  are  in 
error  and  indicating  whether  insufficient  previous  cards  have  been  received. 
This  report  also  warns  of  possible  key  parameter  information  problems  that 
may  be  encountered  in  Phase  2.  Regardless  of  the  error,  all  should  be 
corrected  to  insure  a  sound  database.  The  edits  performed  are  identical 
to  those  for  the  on-line  data  entry  process.  Phase  1  should  be  rerun 
until  an  error-free  run  is  obtained,  or  it  is  determined  that  all  remaining 
errors  are  inconsequential. 

Phase  2 

Most  of  the  database  records  consist  of  multiple  cards,  but  sometimes 
a  card  is  used  to  create  one  database  record  and  occasionally  cards  are 
broken  down  to  produce  multiple  database  records.  Phase  2  performs  the 
function  of  breaking  down  and/or  building  up  the  cards  to  obtain  these 
records.  It  produces  a  sequential  file  and  a  report  which  warns  of  in¬ 
complete  information,  duplicate  information,  or  unidentifiable  data  detected 
in  this  process.  The  report  identifies  the  sequential  number  that  was 
assigned  in  the  first  phase,  pinpointing  the  exact  card  to  be  checked. 

Phase  3 

The  third  and  final  phase  takes  the  records  created  from  Phase  2  after 
all  errors  are  corrected  and  actually  stores  them  onto  the  database  in  their 
appropriate  position.  Again  some  errors  may  be  detected  since  records  are 
connected  to  each  other  in  a  like  fashion  as  the  cards  were  in  Phase  2. 

When  duplicates  are  found,  or  inadequate  connecting  records  are  available, 
then  an  error  is  flagged  to  indicate  further  action  is  required  to  store 


the  record  properly. 


SUSPENSE  REPORT 

There  are  times  when  it  is  appropriate  to  store  cards  onto  the  data¬ 
base  which  have  a  field  in  error.  This  may  be  done  from  the  Initial  Batch 
Load  when  all  of  the  card  edit  errors  are  not  corrected  in  Phase  1  of  that 
process.  Errors  may  also  be  stored  from  on-line  processing.  When  an 
element  fails  to  pass  an  edit,  the  element  will  blink  on  the  screen.  If 
the  error  cannot  be  corrected,  the  user  can  force  the  rest  of  the  data  on 
the  screen  to  be  stored  by  typing  an  "F"  for  forced  update  in  the  command 
field  and  pressing  the  "ENTER"  key.  The  element  in  error  will  be  stored 
as  question  marks.  This  feature  allows  the  valid  data  to  be  stored  and 
available  for  use,  and  saves  the  time  that  would  be  required  to  re-enter 
the  data  from  scratch  later. 

Each  database  record  has  a  suspense  flag  that  will  be  set  when  an  error 
is  stored  in  that  record.  Periodically,  a  Suspense  Report  will  identify 
all  cards  that  have  elements  in  error.  The  software  will  re-edit  all 
records  that  are  flagged  suspended.  If  all  errors  in  the  record  have  been 
corrected,  the  suspense  flag  is  turned  off.  All  remaining  errors  will  be 
included  in  the  Suspense  Report. 

The  Suspense  Report  is  used  to  insure  that  errors  are  identified  so 
that  corrective  action  can  be  taken.  Errors  listed  on  the  report  are 
sorted  by  card  type,  by  LSACN.  The  card  images  correspond  to  the  data 
sheets,  and  errant  data  elements  are  identified.  Errors  may  be  corrected 
by  calling  the  screen  with  the  data  in  error  and  re-entering  the  element 
using  the  Update  Command. 

TURNAROUND  DOCUMENTS 

When  data  are  entered  on  the  database  via  on-line  or  batch  processing, 
the  ALSAR  will  generate  a  Turnaround  Document  if  desired  by  the  user. 

These  hard  copy  printouts  display  information  in  data  sheet  format  and 
provide  additions/changes  to  the  database  that  occurred  during  the 
processing  period  since  the  last  turnaround  was  generated.  When  database 
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transactions  were  modifications  or  updates  to  information  previously 
entered,  the  Turnaround  Document  will  display  a  before  and  after  image. 

The  purpose  of  the  Turnaround  Document  is  to  provide  a  hard  copy 
printout  of  information  actually  loaded  in  the  database  to  functional  area 
users  who  are  responsible  for  the  accuracy  and  completeness  of  the  data. 

Data  elements  that  did  not  pass  edit  checks  and  were  forced  on  the  data¬ 
base  will  appear  as  question  marks  on  the  Turnaround  Document.  The  user  may 
use  this  document  to  verify  and  correct  data  entries.  This  would  be  partic¬ 
ularly  useful  when  engineers/analysts  responsible  for  data  quality  do  not 
actually  perform  the  data  entry.  Managers  could  use  the  Turnaround  Documents 
to  monitor  the  LSA/LSAR  activity  and  for  hard  copy  backup  files,  as  desired. 

PROMPTING  DOCUMENTS 

Although  systems  engineering  is  a  highly  iterative  process  involving 
many  different  functional  areas,  it  can  generally  be  described  in  the  follow¬ 
ing  way.  The  process  starts  with  design  engineering  activity.  Next,  the 
results  of  design  engineering  are  used  by  reliability  engine  ing  to 
accomplish  failure  modes,  effects,  and  criticality  analyses  v,  'r,A)  and  other 
important  functions.  Next,  the  results  of  reliability  engineering  would  be 
used  by  maintainability  engineering  to  determine  the  maintenance  and  support 
requirements  necessary  to  achieve  and  sustain  a  fully  mission  capable  weapon 
system.  These  three  steps  can  be  thought  of  as  occurring  in  a  serial  manner. 
When  maintainability  engineering  completes  the  detailed  task  analyses  and 
identifies  support  requirements  necessary  to  repair  and  sustain  the  weapon 
system  in  operational  status,  the  activities  of  many  other  functional  areas 
may  be  accomplished  in  a  generally  parallel  manner. 

The  ALSAR  system  uses  Prompting  Documents  to  assist  in  the  integra¬ 
tion  of  all  functional  area  activities  involved  in  the  systems  engineering 
process.  When  information  is  entered  in  the  database  by  one  functional 
area,  the  ALSAR  keys  on  selected  data  fields  to  determine  if  the  data 
entered  are  needed  by  another  functional  area  user.  If  so,  the  machine 
generates  a  Prompting  Document  to  that  functional  area.  The  Prompting 
Document  preprints  information  needed  by  the  next  functional  area  to 


accomplish  additional  LSA  and  reminds  the  user  that  additional  LSAR  input 
data  are  now  owed  to  the  system.  The  information  on  the  Prompting  Document 
is  extracted  from  portions  of  the  data  sheets  in  Appendix  A  and  is  presented 
in  a  format  consistent  with  these  data  sheets. 

Figure  10  shows  the  basic  approach  used  to  generate  and  distribute 
Prompting  Documents.  It  is  seen  that  specific  data  sheet  cards  generally 
relate  to  the  functional  area  across  the  top.  The  card  numbers  in  the 
body  of  Figure  10  relate  to  the  data  sheets  in  Appendix  A.  Since  the 
specific  functional  area  responsibilities  may  vary  from  one  organization  to 
another,  the  prompting  scheme  is  table  driven.  That  is,  the  Prompting 
Documents  may  be  flexibly  tailored  to  fit  any  particular  organization. 
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GENERATION  OF  PROMPTING  DOCUMENTS 
FIGURE  10 

Figure  11  shows  the  process  beginning  in  Step  1  with  design  engineering 
entering  a  functional  design  description  of  the  item  under  analysis.  A 
Turnaround  Document  is  sent  back  to  design  engineering,  and  a  Prompting 
Document  is  sent  to  reliability  engineering.  Step  2.  When  reliability  enters 
the  information  it  owes  the  system,  the  process  is  repeated  and  a  Prompting 


Document  is  sent  to  maintainability  engineering.  Step  3.  When  maintain¬ 
ability  engineering  enters  the  information  it  owes  the  system.  Step  4 
simultaneously  sends  prompting  documents  to  one  or  more  functional  areas  as 
shown  on  the  right  side  of  Figure  11,  depending  upon  the  particular  support 
requirements.  That  is,  if  support  requirements  for  that  functional  area 
exist,  a  Prompting  Document  is  sent;  otherwise,  it  is  not  sent. 


USE  OF  PROMPTING  DOCUMENTS 
FIGURE  II 

In  actual  practice  the  systems  engineering  process  should  involve 
Design,  Reliability,  and  Maintainability  Engineering  working  as  a  team  to 
investigate  and  evaluate  alternative  design  concepts  in  an  iterative  closed 
loop  manner.  Similarly,  the  maintainability  engineers  should  team  with 
Provisioning,  Technical  Manuals,  and  other  functional  areas  to  evaluate  the 
overall  support  requirements  and  capabilities.  This  evaluation,  in  turn, 
should  be  fedback  to  the  design  and  R&M  loop  to  insure  that  supportab i 1 i ty 
factors  influence  design  alternatives  and  decisions. 


The  Prompting  Documents  provide  a  useful  mechanism  to  enhance  timely 
integration  and  feedback  in  the  overall  systems  engineering.  Managers 
could  use  this  capability  as  a  tool  to  assist  in  formally  organizing  the 
integration  activity  and  in  monitoring  the  results. 

LSA/LSAR  PROGRESS  REPORTS 

Managers  and  functional  area  analysts  may,  on  occasion,  have  a  need 
to  review  the  current  status  of  the  LSA/LSAR  effort  for  a  given  program. 

The  ALSAR  system  currently  provides  two  reports  for  this  purpose. 

LSACN  Status  Report 

This  report  has  been  designed  to  list  all  of  the  active  LSACNs  associ¬ 
ated  with  a  given  program  effort.  The  report,  which  may  be  requested  using 
an  on-line  menu  screen,  provides  a  list  of  all  currently  active  LSACNs  in 
the  database  for  a  specified  end  item.  For  each  LSACN  the  report  will  list 
all  of  the  data  sheets  that  have  been  entered,  along  with  the  date  that  each 
sheet  was  last  revised.  If  the  LSACN  requires  new  skills,  the  G-Sheet  for 
each  of  the  required  new  skills  is  reported  along  with  the  status  of  each 
G-Sheet.  If  the  LSACN  requires  facilities,  the  F-Sheet  for  each  required 
facility  is  reported  along  with  the  status  of  each  F-Sheet. 

Data  Sheet  Status 

The  ALSAR  system  will  provide  a  hard  copy  printout  of  the  current 
status  of  the  data  sheets  that  exist  for  a  specified  LSACN.  The  on-line 
screen  shown  in  Figure  12  may  be  used  to  obtain  this  output.  The  user 
may  specify  one  or  more  of  the  data  sheets.  The  output  will  include  all 
of  the  information  in  the  database  for  each  sheet  requested,  including 
narrative.  The  format  and  content  of  each  sheet  will  be  identical  to 
those  of  the  corresponding  data  sheet  in  Appendix  A,  except  that  cards  for 
which  no  data  exist  will  be  omitted.  The  data  sheets  requested  will  be 
printed  in  alphabetical  order. 


DPR  LSAOM-OS,  SHEET  REQUEST,  AFMOSD,  AFMOSU 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  AS  OF  xxxxxxx  xx/xx/xx 


SHEET  REQUEST 

THE  FOLLOWING  REQUESTS  REQUIRE 

LSACN  _  ALT -ACT 

A  B  C 

E  F  I 

D  ALSO  REQUIRES  A  TASK  CODE  _____ 

G  ALSO  REQUIRES  A  SKILL  SPEC  CODE  _ 

J  ALSO  REQUIRES  A  DRAWING  NUHBER  _ 

THE  H  SHEET  REQUEST  REQUIRES  _  H 

MPN  _  END- ITEM  LSACN 


i 

i 


DATA  SHEET  STATUS 
FIGURE  12 


REPORTING  SYSTEM 


Many  reports  may  be  generated  by  the  ALSAR  system.  Table  3  lists  the 
reports  that  fully  comply  with  standard  specifications. 

DARCOM  LSA  REPORTS 

The  LSA  summary  reports  shown  in  Table  3  are  the  standard  DARCOM  reports 
that  the  ALSAR  system  is  programmed  to  generate.  The  reports  shown  are 
those  currently  required  by  the  Air  Force.  The  ALSAR  also  generates  the 
D-220  output  for  provisioning  purposes. 


TABLE  3.  ALSAR  OUTPUT  REPORTS 


LSA  SUMMARY  REPORTS 

LSA-01  DIRECT  ANNUAL  MAINTENANCE  MAN-HOUR  BY  SKILL  SPECIALTY 

CODE  AND  CATEGORY  OF  MAINTENANCE 
LSA-02  PERSONNEL  AND  SKILL  SUMMARY 

LSA-03  RELIABILITY  AND  MAINTENANCE  SUMMARY 

LSA- 04  MAINTENANCE  ALLOCATION  SUMMARY 

LSA-05  SUPPORT  ITEM  UTILIZATION  SUMMARY 

LSA-06  CRITICAL  MAINTENANCE  TASK  SUMMARY 

LSA-07  SUPPORT  ITEM  REQUIREMENTS  BY  SKILL  SPECIALTY  CODE 

AND  MAINTENANCE  CATEGORY 

LSA- 08  SUPPORT  ITEM  REQUIREMENTS  BY  MAINTENANCE  CATEGORY 

AND  SKILL  SPECIALTY  CODE 
LSA- 09  SUPPORT  ITEMS  LIST 

LSA- 10  SUPPORT  ITEMS  LIST 

LSA- 11  SPECIAL  TRAINING  DEVICE  SUMMARY 

LSA- 12  SPECIAL  FACILITY  REQUIREMENTS 

LSA- 13  SUPPORT  EQUIPMENT  GROUPING  NUMBER  UTILIZATION 

SUMMARY 

LSA- 14  TRAINING  TASK  LIST 

LSA- 16  PRELIMINARY  MAINTENANCE  ALLOCATION  SUMMARY 

LSA- 17  PRELIMINARY  MAINTENANCE  ALLOCATION  SUMMARY  TOOL  PAGE 

LSA- 20  TOOL  AND  EQUIPMENT  REQUIREMENTS 

LSA-27  SPECIAL  TOOLS  LIST 

LSA- 30  SPECIAL  TOOLS  LIST 

DATA  ITEM  DESCRIPTIONS 

DI-S-6L76  SUPPORT  EQUIPMENT  RECOMMENDATION  DATA  (SERD) 

DI-S-61 77  CALIBRATION  MEASUREMENT  REQUIREMENTS  SUMMARY  (CMRS) 

DI-V-6183A/M  CONSOLIDATED  SUPPORT  EQUIPMENT  LIST  (CSEL) 

DI-L-6147A  PRESENTATION  AND  PACKAGING  DATA 

DI-V-6181/M  REPAIR  PARTS /GSE  PRICE  LIST  (JET  ENGINE) 

DI- V-6I85A/M  LIST  OF  STANDARD /MODIFIED  HAND  TOOLS 

D220  AFLC  PROVISIONING  SYSTEM 

DI- V- 7008  COMMON  BULK  ITEMS  LIST  (CBIL) 

DI-V- 7006/M  INTERIM  SUPPORT  ITEMS  LIST  (ISIL) 

DI-V-7004  LONG  LEAD  ITEMS  LIST  (LLIL) 

DI-V- 7002  PROVISIONING  PARTS  LIST  (PPL) 

DI-V- 7005  REPAIRABLE  ITEMS  LIST  (RIL) 

DI-V- 7007  TOOLS  AND  TEST  EQUIPMENT  LIST  (TTEL) 

DI- V-7016D/M  P RE- PROCUREMENT  SCREENING 

DI-H-3256  TRAINING  EQUIPMENT  LIST  (TEL) 


DATA  ITEM  DESCRIPTIONS  (DID) 


Table  3  also  shows  many  complex  reports  that  the  ALSAR  can  generate 
in  total  compliance  with  standard  DIDs .  The  SERD,  CMRS,  and  CSEL  are 
reports  that  are  extremely  costly  to  accomplish  manually.  Using  the 
ALSAR  procedures  and  conventions,  these  reports  are  completely  machine 
generated.  Likewise,  the  provisioning  technical  documentation  listed 
is  completely  machine  generated. 


REPORT  SELECTION  SCREENS 


All  of  the  reports  listed  in  Table  3  may  be  requested  via  on-line 
report  selection  screens.  Figure  13  is  the  Report  Menu  screen  from  the 
ALSAR  Users  Guide.  Placing  an  X  by  the  desired  report  will  produce  the 


appropriate  Report  Selection  Screen.  For  example,  if  an  X  was  placed 
by  CMRS, the  Report  Selection  Screen  shown  in  Figure  14  would  appear. 
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XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  as  OF  XXXXXXX  XX/ XX,  XX 


REPORT  REQUEST 


LSA01 

LSA02 

LSA03 

LSA04 

LSA05 

LSA06 
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LSA07 

LSA08 

LSA09 

LSA10 

LSA11 

LSAI2 

“ 
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LSA13 

LSA14 

LSA16 

LSA17 

LSA20 

LSA27 

~ 

— 

- 

- 

— 
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LSA30 

CBIL 

CMRS 

CSEL 

D220 

ISIL 

— 

— 

— 

” 

” 

_  LLIL 

MOD-METRIC 

NRLA 

PPL 

RIL 

SERD 

TEL 

TTEL 

PKRQ  PRESERVATION  AND  PACKAGING  DATA 
RPGP  REPAIR  PARTS/GSE  PRICE  LIST 
SMHT  LIST  OF  STANDARD/MODIFIED  HAND  TOOLS 
SCPR  PRE-PROCUREMENT  SCREENING 
LSAS  LSACN  STATUS  REPORT 


ALSAR  REPORT  MENU  SCREEN 
FIGURE  13 
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|  RPTOR- 13,  AFR15D ,  AFR01U 

!  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  AS  OF  XXXXXXXX  XX/ XX/ XX 
REPORT  SELECTION  FOR 

SUPPORT  EQUIPMENT  RECOMMENDATION  DATA  (SERD) 

CALIBRATION/MEASUREMENT  REQUIREMENTS  SUMMARY  (CMRS) 

CONSOLIDATED  SUPPORT  EQUIPMENT  LIST  (CSEL) 

SRV  DES  CD 
LOCATION 
ALT  ACT 
AGCY  CD 
COPIES  _ 

LSACN 

(SERD  ONLY) 

END  ITEM  LSACN 

(CMRS  ONLY) 

END  ITEM  ACRONYM  CODE 

(CMRS  ONLY) 


CMRS  REPORT  SELECTION  SCREEN 
FIGURE  14 


This  screen  is  also  used  to  request  the  SF.RD  and  CSEL  reports.  The  user 
would  then  enter  the  information  necessary  to  specify  the  CMRS  report  for 
the  desired  end  item,  indicate  how  many  copies  are  desired,  and  specify 
the  location  of  the  printer  to  be  used  to  produce  the  hard  copy  report. 

All  of  the  output  reports  have  similar  Report  Selection  Screens, 
with  the  required  report  specification  parameters  listed. 

TAPE  OUTPUTS 

The  ALSAR  system  can  also  generate  tape  outputs  that  may  be  used  as 
input  to  three  standard  models  used  by  the  Air  Force;  the  Mod-Metric , 

NRLA,  and  LOOM. 

Figures  15  and  16  are  the  on-line  Report  Selection  Screens  for 
requesting  the  ALSAR  to  generate  the  output  tapes  for  the  MOD-METRIC 
and  NRLA,  respectively,  A  pseudo  Base  Level  History  Tape  (ABD6DA)  and 
B-4  Master  File  Tape  are  generated  for  input  to  the  LCOM.  The  ALSAR 
Users  Guide  provides  detailed  instructions  for  building  a  constant  data 
file  to  enable  the  ALSAR  to  generate  the  ABD6DA  using  LSAR  data. 

REPORT  REQUEST  SUMMARY 

The  ALSAR  has  an  on-line  screen  that  displays  a  current  status  summary 
of  all  the  reports  that  have  been  requested  by  a  specific  user  but  that 
have  not  been  printed.  This  screen  may  be  used  to  check  the  status  of  a 
report,  to  delete  or  hold  a  report,  or  to  initiate  some  changes  to  the 
original  request. 
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RPT0R-40,  AFR15D,  AFR01U 

xxtooxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  AS  OF  XXXXXXXX  XX /XX/ XX! 

1  REPORT  SELECTION  FOR  MOD-METRIC  ( MODM >  I 

;  j 

|  AGCY  CD  ALT  ACT  j 

j  BUDGET  MIN  BUDGET  MAX  I 

!  LRU  _  BUDGET  _  BACK  ORDER  _ . _  I 

j  OUTPUT  DEVICE  INPUT  DEVICE  DBSO  .  j 


NUMBER  OF  BASES 
FLYING  HOURS 
ORDER  &  SHIP  TIME 


PRINTER  DESIGNATOR  _  PRINT  QUANTITY  _  COMBINE  DEVICE  __  SQOD 


BASE  REPAIR  TIME  _ 

DEPOT  REPAIR  TIME 

PRIME  ALC 

BSTART  _ ._  BSTOP 

_ ._  CFAC  _ 

PBINC  _ . _ 

TITLE 

TITLE/COMMENT 

MOD-METRIC  TAPE  SELECTION  SCREEN 
FIGURE  15 


RPTOR-41 ,  AFR15D,  AFR01U 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  AS  OF  XXXXXXXX  xx/xx/xx 
REPORT  SELECTION  FOR  NETWORK  REPAIR  LEVEL  ANALYSIS  (NRLA) 

AGCY  CD  ALT  ACT 

REQUESTED~LRUS  _  ” _  _  _  _ 


DEPOT  WORK  BREAKDOWN  STRUCTURE 
REPAIR  CYCLE  TIME:  DEPOT  CON 


END  ITEM  ACRONYM  CODE 
DEPOT  OS  BASE 


TYPE  Is 


END  ITEM  NAME 
SERVICE  LIFE 


SENSITIVITY  ALT. 
EXTREMES /COMPLETE 

TYPE  2:  BASE  SHOP  MHRS  _ 

DEPOT  SHOP  MHRS 
TYPE  3:  ORDER/SHIP  TIME  CONUS 
ORDER/SHIP  TIME  OS 
TECHNICAL  COST 


_  NUMBER  BASES 
EQUIV.  WEAP.SYS 
LOWER  RATIO 
RUN  IDENTIFIER 


.99 


.99 


RATIO  OF  FORCE 

OPERATION  HOURS  ' _ 

UPPER  RATIO  .99 


BASE  TURNOVER  RATE  .999 
DEPOT  TURNOVER  RATE  .999 
.999  PACKING  COST  CONUS 

".999  PACKING  COST  OS 


.99 

‘.99 


NRLA  TAPE  SELECTION  SCREEN 


FIGURE  16 
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AIRCRAFT  CHARACTERISTICS  DATA  FILE 


GENERAL 


In  this  section  the  current  development  status  of  the  protvtype 
Aircraft  Characteristics  Data  File  (ACDF)  is  presented  in  summary  form. 

The  reader  is  encouraged  to  review  again  Figure  1  and  the  discussion  of  the 
conceptual  UDB  approach  and  objectives  presented  in  Section  II.  In 
addition,  the  reader  is  encouraged  to  review  again  Figure  3  and  the  dis¬ 
cussion  of  the  UDB  features  relative  to  the  overall  system  objectives. 

PURPOSE  AND  USE 

The  purpose  of  the  ACDF  is  to  provide  a  mechanism  whereby  Government 
and  industry  users  have  convenient  and  timely  access  to  design,  R&M,  and 
support  cost  information  about  existing  operational  aircraft  weapon  systems. 
Primary  users  of  the  ACDF  would  be  those  from  Government  and  industry  who 
are  responsible  for  the  acquisition  and  support  of  new  weapon  systems  and 
equipment . 


m 
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Conceptual  Phase 

In  the  early  weapon  system  planning  stages,  the  ACDF  would  be  useful 
to  those  responsible  for  establishing  system  and  major  subsystem  require¬ 
ments  and  specifications.  The  ACDF  design  and  utilization  data  could  be 
used  to  assist  in  identifying  the  BCS  for  the  new  weapon  system.  When  the 
operational  and  support  concepts  are  formulated,  the  K'.M  and  support  cost 
data  associated  with  the  BCS  would  assist  in  est  iblisbing  the  system  avail¬ 
ability  and  R&M  requirements  and  in  the  a!  la  at  ion  m  Rt.M  system  require¬ 
ments  to  the  subsystem  levels.  In  genera  I  ,  the  \(  at  dot  i  can  t  lieu  be  used 
in  conjunction  with  early  LSA/LSAR  efforts  to  support  and  in!  1  nonce  trade¬ 
off  studies  of  alternate  design  approaches  tor  the  new  weapon  ,vci  ,  i:i. 


Preliminary  and  Detailed  Design  Phases 

As  the  design  activity  proceeds  through  increasing  leveJs  of  detail, 
the  ACDF  may  be  used  to  obtain  BCS  data  at  lower  hardware  indenture  levels. 
The  process  of  using  the  BCS  in  conjunction  with  LSA/LSAR  to  support  design 
tradeoff  studies  and  analyses  can  be  used  throughout  the  preliminary  and 
detailed  design  phases. 

O&S  Phase 

When  the  new  weapon  system  becomes  operational,  the  ACDF  can  be  used 
to  measure  and  evaluate  the  system  performance  in  terms  of  R&M  parameters 
and  support  costs.  Field  data  from  the  MDCS  and  VAMOSC  systems  would  be 
processed  by  ACDF  programs  and  provided  to  users  via  the  on-line  access 
system. 

Research  and  Development  (R&D)  Activities 

Those  organizations  involved  with  R&D  to  develop  new  or  improved 
predictive  models  and  tools  would  be  users  of  the  ACDF.  Timely  and  con¬ 
venient  access  to  this  database  would  greatly  reduce  the  cost  and  increase 
the  effectiveness  of  data  collection  efforts  by  a  large  community  of 
researchers.  The  results  of  R&D  efforts  that  utilize  the  ACDF  for  source 
data  would  be  easier  to  compare  and  validate,  as  opposed  to  those  that 
did  not  use  a  common  data  source. 

TECHNICAL  APPROACH 

The  ACDF  was  developed  under  the  concept  that  it  would  eventually 
be  implemented  and  maintained  at  a  central  Government  facility.  Since 
the  specific  machine  and  software  environment  to  house  the  ACDF  was  not 
known,  there  was  a  strict  requirement  to  design  the  system  for  optimal  trails 
portability.  As  a  result  of  this  requirement,  and  the  need  for  an  efficient 
on-line  capability  to  serve  remote  users,  the  ACDF  was  designed  as  an 
interactive  Time-Sharing  Option  (TSO)  system  that  utilizes  the  Virtual 
Storage  Access  Method  (VSAM) .  Application  programs  are 
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in  American  National  Standard  Common  Business  Oriented  Language  (ANS  COBOL) 
VSAM  records  are  designed  to  group  or  categorize  data  in  a  manner  intended 
to  ehhance  the  utility  of  the  ACDF  to  multiple  users  and  the  efficiency 
of  operating  the  system. 

MODES  OF  OPERATION 

Data  Entry  -  The  ACDF  system  data  files  would  be  initially  loaded 
and  subsequently  updated  by  the  organization  responsible  for  operation  and 
maintenance  of  the  ACDF.  Batch  load  programs  would  be  used  for  data  entry, 
which  would  be  be  accomplished  by  the  host  computer  facility.  Remote 
on-line  users  would  not  have  the  capability  to  enter  or  modify  data  in 
the  ACDF. 

Data  Retrieval  -  Data  loaded  in  the  ACDF  may  be  retrieved  by  any 
authorized  user  via  on-line  CRT  terminal  screen,  or  batch  output  programs 
generating  hard  copy  printouts.  Users  may  specify  and  request  hard  copy 
outputs  using  the  on-line  mode  of  operation.  The  ACDF  output  for  speci¬ 
fied  data  is  presented  in  the  same  image,  form,  and  content,  whether 
displayed  on  the  CRT  or  hard  copy.  Users  operating  CRT  terminals  with 
screen  image  printers  could  obtain  hard  copy  of  selected  data.  The  system 
is  designed  to  permit  dial-up  line  access  to  the  ACDF. 

DOCUMENTATION 

Table  4  lists  the  documents  that  record  the  results  of  the  ACDF 
development  effort.  This  documentation,  dated  April  1983,  has  been 
delivered  to  the  Air  Force. 


TABLE  4.  ACDF  DOCUMENTATION 


DOCUMENT _ 

ACDF  Data  Element 
Descriptions  (DED) 

ACDF  Data  Input  Record 
Layout 


_ PURPOSE _ 

Defines  each  data  element 
in  each  ACDF  Record 

Defines  the  record  layouts 
for  data  input  to  ACDF 


ACDF  Users  Guide 

ACDF  Programming 
Documentation 


Provides  instructions  for  use 
of  the  on-line  system 

Contains  all  programs  developed 
for  operation  of  the  ACDF 


ACDF  DED 

Unlike  the  ALSAR  which  used  DARCOMP  750-16  as  the  baseline,  no  base¬ 
line  system  was  available  for  the  ACDF.  As  a  result,  the  data  elements 
in  the  DED  were  selected  on  the  basis  of  the  previous  work  by  Thomas  and 
Hankins  (1980) ,  which  included  a  major  industry  survey  that  investigated 
the  data  needs  of  those  responsible  for  weapon  system  design,  R&M,  and 
logistics  support.  The  ACDF  DED  provides  the  definition  for  each  data 
element  in  the  system,  including  the  field  size  and  other  characteristics. 
The  data  elements  are  then  organized  into  specific  records  for  greater 
utility  to  the  user  when  retrieving  ACDF  data. 

Data  Input  Record  Layouts 

This  document  contains  the  data  sheets  depicting  the  layouts  for  each 
record  in  the  ACDF.  Those  responsible  for  loading  data  in  the  ACDF  would 
use  these  data  sheets  in  conjunction  with  the  DED  to  input  data.  There 
are  66  data  input  sheets  covering  all  of  the  ACDF  records.  An  example  of 
the  data  sheets  is  shown  in  Figure  17,  which  includes  a  portion  of  the 
System  Features,  Electrical  Power  Supply,  and  Hydraulic  Power  Supply  Records 

Users  Guide 

Thiis  document  provides  detailed  instructions  for  using  the  on-line 
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system  to  retrieve  data  from  the  ACDF.  Procedures  are  given  to  retrieve 
data  from  each  record,  and  for  special  functions  that  present  data  from 
multiple  records.  The  manner  in  which  the  data  are  displayed  on  the  CRT 
terminal  screen  for  each  record  is  also  described  in  the  Users  Guide. 

Programming  Documentation 

This  480-page  document  includes  a  description  of  each  COBOL  applica¬ 
tion  program  associated  with  the  ACDF.  Documentation  on  each  program 
includes  the  program  name,  calling  and  called  programs,  copy  code,  VSAM 
or  sequential  files  accessed,  function  of  the  program,  and  the  method¬ 
ology  used.  The  source  code  for  each  program  is  also  included. 

ACDF  RECORD  CONTENTS 

The  records  described  in  the  DED  are  listed  in  Table  5.  The  ACDF 
would  contain  information  in  each  one  of  those  records  about  each  air¬ 
craft's  MDS.  A  brief  description  of  the  contents  of  these  records  is 
presented  next. 

TABLE  5.  ACDF  RECORDS  FOR  EACH  AIRCRAFT  MDS 


SYSTEM  RECORDS 

AIRCRAFT  GENERAL 
MISSION 

BASIC  MISSION  PERFORMANCE 
SYSTEM  DESIGN  AND  PERFORMANCE 
ENGINE 

SYSTEM  UTILIZATION 
SYSTEM  FEATURES 
SYSTEM  R&M/COST 
OPERATIONAL  R&M/COST 
NATIONAL  STOCK  NUMBER 


SUBSYSTEM  RECORDS 

AIRFRAME 

AVIONICS 

CREW  STATION 

ELECTRICAL  POWER 

ENVIRONMENTAL  CONTROL 

FLIGHT  CONTROL 

FUEL 

HYDRAULIC  POWER 

LANDING  GEAR 

POWER  PLANT  INSTALLATION 


AIRCRAFT  RECORD 

This  record  is  basically  header  information  that  provides  a  top 
level  description  of  a  particular  aircraft  weapon  system. 
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MISSION  RECORD 


This  record  contains  narrative  information  from  the  Air  Force  Guide 
(AFG-2)  briefly  describing  the  primary  and  secondary  missions  of  an  air¬ 
craft  MDS. 

BASIC  MISSION  PERFORMANCE  RECORD 

This  record  contains  information  from  the  AFG-2  for  the  basic  mission 
performance.  The  data  elements  and  definitions  are  consistent  with  AFG-2. 
The  record  is  designed  to  accommodate  differences  in  AFG-2  data  between 
aircraft  MDS. 

SYSTEM  DESIGN  AND  PERFORMANCE  RECORD 

This  record  contains  information  about  top-level  system  design  and 
operational  performance  characteristics  of  an  aircraft  MDS.  The  informa¬ 
tion  includes  dimensions,  weights,  thrust,  speeds,  range,  rate  of  climb, 
and  altitudes.  It  also  provides  the  total  number  of  2-,  3-,  4-,  and 
5-digit  WUC  items  associated  with  an  aircraft  MDS. 

ENGINE  RECORD 

This  record  contains  AFG-3  design  and  performance  information  about 
engines  used  in  operational  aircraft  MDS.  The  data  elements  and  defini¬ 
tions  are  consistent  with  AFG-3.  The  record  is  designed  to  accommodate 
differences  in  AFG-3  data  between  engine  types  and  models. 

SYSTEM  UTILIZATION  RECORD 

This  record  contains  information  about  the  fleet  utilization  of  an 
aircraft  MDS.  It  includes  the  active  inventory,  base  level  flying  time 
and  sorties,  average  sortie  length,  and  other  relevant  fleet  information. 

SYSTEM  FEATURES  RECORD 

This  record  contains  information  about  top-level  system  design 
features  incorporated  on  an  aircraft  MDS.  The  features  include  weight  cla 


number  of  aircrew  personnel,  type  crew  escape  system,  type  engines,  number 
of  engines,  type  engine  installation,  wing  geometry,  type  flight  controls, 
type  and  number  of  electrical  and  hydraulic  systems,  type  avionics  installed 
built-in-test  units,  and  many  other  features. 

AVIONICS  SYSTEMS  RECORD 

This  record  contains  information  that  identifies  avionics  equipment, 
by  standard  equipment  nomenclature  (SEN) ,  that  is  installed  on  an  aircraft 
MDS.  For  each  SEN  the  record  specifies  whether  or  not  built-in-test  pro¬ 
visions  are  incorporated. 

SYSTEM  R&M  COST  RECORD 

This  record  contains  top  system  level  R&M  and  cost  information  for 
an  aircraft  MDS.  The  information  includes  unit  fly-away  cost,  system 
level  support  costs,  base  and  depot  level  maintenance  manhours,  base 
level  maintenance  manhours  per  flying  hour  (MMH/FH)  and  sortie,  and  overall 
MMH/FH. 

OPERATIONAL  SUPPORT  AND  COST  RECORD 

This  record  contains  detailed  R&M  and  support  cost  information  for 
a  weapon  system.  There  are  five  sub-records,  all  of  which  will  be  useful 
to  those  responsible  for  LSA/LSAR  activity  on  new  system  acquisition 
programs. 

Aircraft  Level /AFR  800-18  Format  4 

This  sub-record  provides  system  level  R&M  data  in  the  format  and 
content  specified  by  Air  Force  Regulation  (AFR)  800-18,  "Reliability  and 
Maintainability  Program"  (formerly  AFR  80-5).  This  record  breaks  out  pre¬ 
ventive  and  corrective  maintenance  into  all  the  required  categories  addressed 
in  LSAR,  and  provides  standard  R&M  parameter  terms  for  each  category. 


Work  Center  by  Aircraft 


This  sub-record  groups  R&M  data  by  work  centers  associated  with  an 
aircraft  MDS.  For  a  large  aircraft  MDS,  this  record  could  contain  data  for 
approximately  thirty  (30)  work  centers. 

Support  Cost  by  WUC 

This  sub-record  contains  support  cost  information  that  may  be 
retrieved  at  the  5-digit  WUC  level,  or  summarized  at  the  2-,  3-,  or  4-digit 
WUC  levels.  The  machine  stores  only  the  5-digit  WUC  data,  and  internal 
programs  calculate  summarized  values  on  request  by  users.  The  data  elements 
and  definitions  in  this  record  are  consistent  with  VAMOSC  data  elements 
related  to  cost. 

R&M  Data  by  WUC 

This  sub-record  contains  R&M  parameter  data  at  the  lower  levels  of 
WUC  indentures.  The  data  are  expressed  in  terms  compatible  with  those 
required  for  detailed  levels  of  LSA/LSAR  for  new  system  acquisition 
programs . 

Maintenance  Action  by  WUC 

This  sub-record  contains  summary  data  by  WUC,  sorted  by  standard  Air 
Force  maintenance  "action  taken,"  "how  malfunctioned,"  and  "type  how 
malfunctioned"  codes.  The  reader  may  recognize  that  provisions  on  the 
B-  and  D-Sheets  of  the  ALSAR  will  relate  to  this  sub-record  in  the  ACDF. 

NATIONAL  STOCK  NUMBER  RECORD 

This  record  contains  information  that  enables  users  to  cross-reference 
a  National  Stock  Number  (NSN)  to  a  part  number,  determine  each  aircraft  MDS 
that  uses  the  NSN,  and  determine  the  WUC  assigned  to  the  NSN  on  a  given 
aircraft  MDS.  In  addition,  the  record  contains  cost  and  weight  information 
about  an  NSN. 


SUBSYSTEM  RECORDS 


There  are  nine  individual  subsystem  records  in  the  ACDF.  These 
include  airframe,  crew  station,  environmental  control,  electrical  power, 
flight  controls,  fuel,  hydraulics,  landing  gear,  and  power  plant.  The 
Avionic  Systems  Record  was  discussed  earlier.  Each  subsystem  record  con¬ 
tains  design,  weight,  and  WUC/NSN  cross-reference  information. 

Designers  and  logisticians  could  use  the  subsystem  records  through¬ 
out  the  design  and  development  activity  for  a  new  system  acquisition 
program.  The  WUC/NSN  cross-reference  could  be  used  in  conjunction  with 
the  NSN  and  Operational  Support /Cost  Records  to  evaluate  the  performance  of 
equipment  in  various  aircraft  MDSs. 

ON-LINE  SYSTEM 


The  on-line  interactive  system  is  designed  to  permit  users  to  request 
information  selectively  and  have  it  displayed  on  remote  CRT  terminal  screens. 
The  ACDF  database  is  actually  structured  in  accordance  with  the  records  in 
Table  5.  Functionally  the  database  may  be  viewed  in  a  manner  similar  to 
that  shown  in  Figure  18.  The  database  is  designed  to  facilitate  retrieval 
of  all  or  part  of  the  information  in  the  database  about  a  particular  aircraft 
MDS. 

The  ACDF  provides  design  and  weight  information  for  each  subsystem 
record.  It  also  provides  WUC/NSN  cross-reference  information.  The  WUC 
can  then  be  used  to  retrieve  desired  R&M  and  support  cost  information  about 
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MISSIONS 


SYSTEM  LEVEL 


SUBSYSTEM  LEVEL 


TOR  EACH  SUBSYSTEM 

1.  SUBSYSTEM  DESIGN 

2.  SUBSYSTEM  WEIGHT 

3.  SUBSYSTEM  WUC  BREAK- 
DOWN/MSN  X-REF 


4.  SUPPORT/COST 

•  2-DIGIT  WUC  SUMMARY 

•  5-OIGIT  WUC  INFORMATION 


WUC 

SUBSYSTEM 

M  .000 

airframe 

12,000 

CRfW  STATION 

13.000 

LANDING  GEAR 

11*  ,000 

FLIGHT  CONTROL 

16,000 

ESCAPE  CAPSULE 

20.000 

P0WEK  PLANT  1  EMC  1  HE) 

41  ,000 

AIR  CONT. .  etc. 

42.000 

ELECT.  POWER  SUPPLY 

45.000 

HYO.  POWER  SUPPLY 

etc. 

SYSTEM  DESIGN/ 
PERFORMANCE 
ENVELOPE  AND 
BASIC  MISSION 
PARAMETERS 


SYSTEM 

UTILIZA¬ 

TION 

RECORD 


SYSTEM 

SUPPORT 

(Ram)  and 
cost 


BASIC  SYSTEM 
FEATURES 


FUNCTIONAL  DISPLAY  OF  ACDF  DATABASE 
FIGURE  18 


RECORD  COMMANDS 

Once  the  user  is  logged  on  and  "READY"  appears  on  the  screen,  typing 
the  "ACDF"  command  will  retrieve  the  menu  screen  shown  in  Figure  19.  The 
user  may  then  select  and  enter  the  CODE  for  the  desired  RECORD  NAME  shown 
in  Figure  19.  When  the  desired  record  code  is  entered,  the  machine  will 
prompt  the  user  to  enter  the  aircraft  MDS  of  interest.  When  the  appro¬ 
priate  MDS  is  entered,  the  ACDF  will  display  the  requested  information 
on  the  CRT  terminal  screen.  If  the  user  desires  all  of  the  information 
in  the  ACDF  about  a  particular  MDS,  the  user  would  enter  "ALL"  rather  than 
the  code  for  one  record.  The  system  will  then  display  the  information  in 
all  of  the  ACDF  records  for  the  aircraft  MDS  specified. 
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!  WELCOME  TO  THE  AIRCRAFT  CHARACTERISTIC  DATA  BASE 
PLEASE  ENTER  CODE  FOR  RECORD  NAME  DESIRED 


CODE 

RECORD  NAME 

CODE 

RECORD  NAME 

ACF 

AIRCRAFT 

HPR 

HYDRAULIC  AND  PNEUMATIC 

AFR 

AIRFRAME  SUBSYSTEM 

LGR 

LANDING  GEAR  SUBSYSTEM 

AVS 

AVIONICS  SYSTEMS 

MDR 

MISSION  AND  DESCRIPTION 

BMR 

BASIC  MISSION 

NSN 

NATIONAL  STOCK  NUMBER 

CSF 

CREW  STATION  &  FUSELAGE  DATA 

OSC 

OPR  SUPPORT/COST 

ECS 

ENVIRONMENTAL  CONTROL  SUBSYSTEM 

PPS 

POWER  PLANT  SUBSYSTEM 

ENG 

ENGINE  DATA 

SDP 

SYSTEM  DESIGN  &  PERFORMANCE 

EPS 

ELECTRICAL  POWER  SUPPLY 

SRM 

SYSTEM  R  &  M  COST 

FCR 

FLIGHT  CONTROL  SUBSYSTEM 

UTI 

SYSTEM  UTILIZATION 

FEA 

SYSTEM  FEATURES 

FSR 

FUEL  SUBSYSTEM 

END 

TO  END  THIS  JOB 

PLEASE  ENTER  CODE  FOR  INQUIRY  MODE  DESIRED 


CODE  INQUIRY  MODE 


j  LAC  LIST  ALL  AIRCRAFT  MDS  AND  SRD 

LAV  LIST  ALL  AVIONICS  EQUIPMENT  SRD 

LDE  LIST  DATA  ELEMENTS  WITH  RECORD  CODE 

|  LEN  LIST  ALL  ENGINE  MODEL  NUMBERS 

|  SEL  SELECT  ALL  AIRCRAFT  WITH  A  SYSTEM  FEATURE 

I  SEL  LIST  DISPLAY  A  LIST  OF  SELECTABLE  FEATURES  WITH  INDEX  VALUES 


ACDF  RECORD  SELECTION  DISPLAY  SCREEN 
FIGURE  19 


QUERY  COMMANDS 


The  interactive  ACDF  system  enables  the  user  to  query  the  system  for 
selected  information.  The  CODE  for  each  of  several  INQUIRY  MODES  is  listed 
at  the  bottom  of  the  RECORD  SELECTION  DISPLAY  screen  shown  in  Figure  19. 


LAC  Command 


When  the  user  enters  this  command,  the  MDS  and  Standard  Reporting 
Designator  (SRD)  will  be  displayed  for  each  aircraft  weapon  system  for 
which  data  exist  in  the  ACDF. 


LAV  Command 


When  the  user  enters  this  command,  the  Standard  Equipment  Nomenclature 
(SEN)  will  be  displayed  for  all  avionics  equipment  in  the  ACDF. 


LDE  Command 


When  the  user  enters  the  LDE  command,  an  alphabetical  listing  of  all 
the  data  elements  in  the  ACDF  is  displayed  showing  the  record  in  which  it 
is  used.  This  feature  would  be  particularly  useful  when  the  user  is 
interested  in  one  or  more  specific  data  elements,  but  does  not  know  how 
to  retrieve  them. 

LEN  Command 

When  the  user  enters  the  LEN  command,  a  list  of  all  engine  model  numbers 
in  the  Engine  Record  is  displayed. 

SEL  List  Command 

The  System  Features  (FEA)  record  contains  data  elements  that  describe 
basic  characteristics  of  an  aircraft  weapon  system.  When  the  user  enters 
the  FEA  command,  the  machine  will  prompt  for  the  desired  aircraft  MDS.  When 
the  MDS  is  entered,  the  machine  will  display  all  of  the  system  features  that 
are  incorporated  on  that  MDS. 

The  SEL  LIST  command,  when  entered,  will  display  a  list  of  all  of  the 
data  elements  in  the  System  Features  Record,  along  with  an  Index  Number  for 
each  feature  as  shown  in  Table  6.  In  addition,  the  machine  will  prompt  the 
user  to  enter  the  Index  Number  of  interest.  When  this  is  accomplished,  the 
machine  will  display  all  of  the  aircraft  MDSs  that  have  the  selected 
features . 

Some  of  the  system  features  will  require  additional  information,  which 
the  machine  will  prompt  the  user  to  provide.  For  example,  when  the  user 
wants  to  find  all  aircraft  MDSs  that  have  two  engines  embedded  in  the 
fuselage,  Index  Number  10  is  to  be  entered  bv  the  user.  The  machine  would 
then  prompt  the  user  to  enter  the  number  of  engines.  When  "2"  is  entered, 
the  system  would  display  all  aircraft  MDSs  that  have  two  engines  embedded 
in  the  fuselage. 


TABLE  6.  SYSTEM  FEATURES  RECORD 


If.'SEM  VALUES  OF  SYSTEM  FEATURES  AVAILABLE  FOR  INQUIRY 


INDEX 

FEATURE 

INDEX 

FEATURE 

1 

MANUFACTURER 

-* 

2 

AIRCRAFT  TYPE 

41 

A/A  MISSILES 

3 

PRIMARY  MISSION 

42 

A/G  MISSILES 

4 

WEIGHT  CLASS 

43 

CRUISE  MISSILES 

5 

AIRCRAFT  DENSITY 

44 

RFS 

6 

NUMBER  AIRCREW 

45 

HUD 

7 

CREW  ESCAPE 

46 

ECM 

8 

TYPE  ENGINE 

47 

INTERNAL  GUNS 

9 

TOTAL  NUMBER  OF  ENGINES 

48 

ON-BOARD  MAINTENANCE  RECORDER 

10 

NO  OF  ENGINES  IN  FUSELAGE 

49 

LANDING  GEAR  TYPE 

11 

HO  OF  ENGINE  ON  FUSELAGE  PODS 

50 

NUMBER  OF  LANDING  GEARS 

12 

NO  OF  ENGINE  I”  WINGS 

51 

NUMBER  OF  WHEELS/TIRES 

13 

NO  OF  ENGINE  ON  WING  PODS 

52 

DE-ICING 

14 

TYPE  ENGINE  INSTALLATION 

53 

ANTI-ICING 

15 

ENGINE  augukehted 

54 

BLEED  AIR  SYSTEM 

16 

VARIABLE  GEOMETRY  TNLETS 

55 

TYPE  OF  OXYGEN 

17 

THRUST  REVERSER 

56 

AUTO  PILOT  SYSTEM 

18 

WING  LOCATION 

57 

AUTO  PILOT/ILS  COUPLED 

19 

VARIABLE  WING  Gt( 

58 

TERRAIN  FOLLOWING/TERRAIN  AVOIDANCE  (TF/TA) 

20 

WINGS  WITH  INTERNAL  FUEL  TANKS 

59 

AUTO  PILOT  COUPLED  TO  TF/TA 

21 

HIGH  TECHNOLOGY  WING 

60 

AUTO  PILOT  COUPLED  TO  WEAPON  DELIVERY  SYSTEM 

22 

BOUNDARY  LAYER  CONTROL 

61 

FLIGHT  DIRECTOR 

23 

INDEPENDENT  FLIGHT  CONTROL 

62 

WEAPON  CONTROL  SYSTEM 

24 

FLY-BY-WIRE  CONTROL  SYSTEM 

63 

EXTERNAL  STORE  STATIONS 

25 

STABILITY/CONTROL  SYSTEM 

64 

CAMERAS  ON  BOARD 

26 

ELECTRICAL  MULTIPLEX 

65 

AIR-TO-AIR  REFUELING 

27 

INDEPENDENT  ELECTRICAL  POWER 

66 

WINDSHIELD  RAIN  REMOVAL 

28 

AUXILLARY  POWER  UNITS 

67 

AIR  TURBINE  MOTORS 

29 

INDEPENDENT  HYDRAULIC  POWER 

68 

AVIONICS  EQUIPMENT  COOLING 

30 

HYDRAULIC  SYSTEM  PRESSUPE 

69 

RADAR  ALTIMETER 

31 

HYDRAULIC  DEPENDENT  SUBSYSTEMS 

70 

CRASH  DATA  RECORDER 

32 

HF  COMMUNICATION  SYSTEM 

71 

EMERGENCY  RADIO  BEACON 

33 

VHP  COMMUNICATION  SYSTEM 

72 

COMMAND /CONTROL  EQUIPMENT 

34 

UHF  COMMUNICATION  SYSTEM 

73 

FIRE  SUPPRESSION  SYSTEM 

35 

FM  COMMUNICATION  SYSTEM 

74 

LANDING  GEAR  KNEELING 

36 

RADIO  NAVIGATION  SYSTEM 

75 

LANDING  GEAR  CASTERING/STEERING 

37 

RADAR  NAVIGATION  SYSTEM 

76 

TAIL  BUMPER 

38 

A/A  RADAR 

77 

BUILT-IN-TEST  SYSTEMS 

39 

IR  NAVIGATION  SYSTEM 

78 

STRUCTURAL  COMPOSITE  MATERIAL 

40 

ELECTRO  -  OPTICAL 

79 

AVIONICS/WEAPON  CONTROL  COMPUTER  SYSTEM 

AVS  Vers 1 1  s _ Equipment 

If  the  user  wants  to  know  the  avionics  equipment  installed  on  a 
given  aircraft  MDS,  the  user  would  enter  AVS  and  the  MDS .  If  the  user 
wants  to  know  all  of  the  MDS  that  use  a  particular  piece  of  avionics 
equipment,  the  user  would  enter  AVS  and  the  SEN  for  the  equipment. 
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Engine  Data 

Using  the  Engine  Record  (ENG) ,  special  prompts  are  available  that 
permit  the  user  (a)  to  obtain  all  the  data  associated  with  the  engine 
installed  on  a  given  aircraft  MDS ,  (b)  to  find  all  aircraft  MDSs  that  use 
a  particular  engine,  and  (c)  to  obtain  all  the  information  available  about 
a  particular  engine. 

National  Stock  Number  Data 

Using  the  National  Stock  Number  Record  (NSN) ,  special  prompts  are 
available  (a)  to  find  all  aircraft  MDSs  that  use  a  particular  NSN  in  a 
specified  major  subsystem,  (b)  to  find  all  aircraft  MDSs  that  use  a  partic¬ 
ular  manufacturer's  part  number  (MPN)  in  a  specified  major  subsystem,  (c)  to 
find  all  the  major  subsystems  on  a  particular  aircraft  MDS  that  utilize  a 
specified  NSN,  and  (d)  to  find  all  data  for  a  particular  NSN  installed  in  a 
specified  major  subsystem  and  aircraft  MDS. 

ON-LINE  CRT  SCREENS 

Data  retrieved  from  the  ACDF  system  will  be  displayed  on  remote  CRT 
terminal  screens.  Many  of  the  screens  for  the  ACDF  records  are  included  in 
Appendix  B.  The  data  would  be  displayed  exactly  as  shown  for  each  record. 
When  all  of  the  available  data  will  not  fit  on  a  screen  image,  the  continued 
data  would  automatically  wraparound  to  the  next  screen. 


HARD  COPY  DATA 

The  on-line  system  permits  users  to  request  hard  copy  printouts  of  ACDF 
data.  The  ACDF  Users  Guide  provides  instructions  for  requesting  batch  print 
outs.  The  outputs  will  be  displayed  in  the  same  form  and  content  as  shown 
in  Appendix  B. 


SECTION  V 


AFOTEC  AND  COMBAT  DATA 

GENERAL 


The  UDB  development  program  effort  covered  in  the  previous  sections  was 
accomplished  by  Clemson  University.  Two  additional  efforts  that  were 
relatively  small  in  scope  were  accomplished  as  part  of  the  UDB  development 
program.  The  first  was  a  study  of  the  OT&E  requirements  for  a  new  weapon 
system,  which  was  accomplished  by  the  BDM  Corporation.  The  second  was  a 
study  of  combat  data  sources,  which  was  accomplished  by  the  McDonnell-Douglas 
Astronautics  Company 


OT&E  REQUIREMENTS 


OBJECTIVES  AND  APPROACH 

The  objectives  of  this  effort  were,  first,  to  investigate  the  data  input 
and  output  requirements  of  the  Air  Force  Operational  Test  and  Evaluation 
Center  (AFOTEC)  during  an  aircraft  OT&E  suitability  assessment  and,  second, 
to  determine  the  extent  to  which  the  prototype  UDB  would  satisfy  these 
needs.  Two  major  tasks  were  undertaken  to  satisfy  these  objectives.  The 
first  was  to  identify  and  evaluate  all  of  the  data  input  requirements  and 
data  output  products  of  the  standard  AFOTEC  computer  programs  used  in  an 
aircraft  OT&E  suitability  assessment.  The  second  task  was  to  compare  the 
ALSAR  and  ACDF  capabilities  of  the  UDB  with  the  results  of  the  first  task. 

AFOTEC  INPUTS  AND  OUTPUTS 

Table  7  lists  the  primary  systems  used  by  AFOTEC.  The  data  elements 
required  for  input  to  each  one  of  these  systems  were  defined.  Similarly, 
the  output  products  of  each  one  of  these  systems  were  defined,  and  the 
individual  data  elements  of  each  product  were  identified.  A  matrix  was 
developed  for  both  input  requirements  and  output  products,  showing 
individual  data  elements  by  source  and  system  used. 


TABLE  7.  AFOTEC  SYSTEMS  USED 


INPUT 

REQUIRE¬ 

MENTS 

OUTPUT 

PRODUCTS 

SYSTEM  USED 

X 

D056 

- 

AFLC  Product  Performance  System 

X 

MDCS 

- 

Maintenance  Data  Collection  System 

X 

SEDS 

- 

System  Effectiveness  Data  System 

X 

MILAP 

- 

Maintenance  Information  Logically 
Analyzed  and  Presented 

X 

MMICS 

— 

Maintenance  Management  Information 
and  Control  System 

X 

CDEP 

- 

Common  Data  Extraction  Programs 

X 

X 

MISEDS 

Machine  Independent  Systems 
Effectiveness  Data  System 

X 

X 

OMNIVORE 

- 

AFT  EC  Data  Base  Access  and  Analysis 
Sys  tern 

X 

X 

COO 

Cost  of  Ownership  Model 

X 

X 

LCOM 

- 

Logistics  Composite  Model 

X 

X 

MCSP 

- 

Mission  Completion  Success 
Probability  Model 

UDB  CAPABILITY 

Using  the  matrices  developed  in  the  task  above,  a  comprehensive  list 
of  data  elements  was  prepared  to  define  the  specific  input  and  output  require¬ 
ments  of  AFOTEC.  This  list  was  compared  with  the  ALSAR  and  ACDF  system 
capability  of  the  prototype  UDB.  As  a  result,  approximately  80  data  elements 
were  identified  that  could  not  be  supported  by  the  existing  UDB. 

OT&E  RESULTS 

The  results  of  the  OT&E  requirements  effort  were  documented  by  the 
BDM  Corporation  and  delivered  to  the  Air  Force  in  April  1982.  The  objectives 
of  this  effort  were  fully  satisfied,  and  the  results  will  be  used  in  future 
UDB  development  efforts. 


COMBAT  REQUIREMENTS 


OBJECTIVES  AND  APPROACH 

The  objective  of  this  effort  was  to  investigate  the  feasibility  of  a 
combat  unified  retrieval  system  and  its  incorporation  into  the  UDB  system. 
The  approach  included  tasks  (a)  to  investigate  and  identify  all  significant 
sources  of  data  on  maintenance  and  logistics  support  in  combat  environments 
and  also  to  identify  available  combat  data  retrieval  and  generating  tech¬ 
nologies,  (b)  to  collect  a  representative  sample  of  combat  data  from 
available  identified  sources,  (c)  to  analyze  potential  approaches  and  design 
requirements,  including  software,  necessary  for  the  Air  Force  to  obtain, 
store,  and  access  this  combat  information,  and  (d)  to  outline  corresponding 
detailed  design  requirements,  for  a  combat  database,  that  are  compatible 
with  the  prototype  UDB,  and  that  will  allow  for  combat  information  retrieval 

SUMMARY  OF  RESULTS 

The  results  of  this  effort  were  documented  by  McDonnell -Douglas 
Astronautics  Company  and  delivered  to  the  Air  Force  in  March  1983.  The 
report  provides  a  discussion  of  available  rombat  data  sources  and  related 
information,  and  provides  sample  combat  data  that  could  be  included  in  a 
Combat  Unified  Retrieval  System  (CURS). 

The  report  concluded  that  it  would  be  possible  to  use  the  UDB  system 
as  the  baseline  for  the  development  of  a  CURS.  The  detailed  design  require¬ 
ments  for  a  CURS  and  UDB  interface  were  not  defined. 


SECTION  VI 


CONCLUSIONS  AND  RECOMMENDATIONS 
FOR 

FUTURE  DEVELOPMENT 


CONCLUSIONS 


The  UDB  will  satisfy  many  of  the  objectives  discussed  in  Section  II  and 
shown  in  Figure  1.  Progress  to  date  has  demonstrated  that  it  is  technically 
feasible  to  achieve  all  of  the  objectives  of  the  conceptual  closed-loop  UDB 
system.  While  much  development  work  remains  to  be  accomplished,  the  ALSAR  and 
ACDF  systems  provide  a  solid  foundation  on  which  future  development  efforts 
can  build. 

The  ALSAR  is  a  fully  automated  and  advanced  system  that  is  being  used 
in  a  production  mode  to  support  the  defensive  avionics  portion  of  the  B-lB 
program.  Since  this  is  its  first  application,  the  system  has  not  yet  been 
validated.  The  ALSAR  has  performed  satisfactorily  to  date,  and  numerous 
problems  in  the  system  have  been  corrected.  As  the  B-lB  program  progresses, 
the  ALSAR  system  will  be  increasingly  validated. 

The  ACDF  system  has  been  initially  developed,  but  is  far  behind  the 
ALSAR  in  terms  of  verification  testing.  All  of  the  ACDF  features  covered 
in  Section  IV  are  available  in  the  prototype,  but  additional  development 
work  will  be  needed  before  it  is  ready  to  be  implemented  by  the  Air  Force. 

FUTURE  RESEARCH  AND  DEVELOPMENT 


Future  UDB  development  efforts  should  include  tasks  necessary  to 
fully  achieve  the  closed-loop  UDB  objectives  discussed  in  Section  II  and 
shown  in  Figure  1.  In  addition,  work  to  enhance  the  overall  UDB  system 
should  be  accomplished  in  future  efforts.  Specific  recommendations  for 
future  R&D  work  are  presented  in  the  following  paragraphs. 


ALSAR 


Production  Support  and  Software  Maintenance 


Production  support  to  the  B-1B,  and  possibly  other  development  pro¬ 
grams,  should  continue  using  the  existing  ALSAR  system.  Until  such  time 
that  the  existing  ALSAR  is  fully  validated,  this  effort  will  require  soft¬ 
ware  maintenance  support  to  fix  problems  when  they  are  discovered.  If 
program  users  are  operating  remotely  from  the  host  ALSAR  facility,  production 
support  will  be  required  from  the  host. 

From  the  standpoint  of  the  UDB  development  program,  continued  support 
to  programs  using  the  existing  ALSAR  is  necessary  to  validate  the  advanced 
features  of  the  system.  From  the  standpoint  of  Air  Force  acquisition 
programs,  the  existing  ALSAR  system  fully  satisfies  current  Air  Force  and  DOD 
requirements  and  is  available  now  as  Government  property. 

Redesign  to  Support  MIL-STD-1388-2A 


The  ALSAR  was  designed  and  developed  using  DARCOMP  750-16  as  the 
baseline.  When  MIL-STD-1388-2A  is  approved,  the  ALSAR  system  should  be 
redesigned  to  support  this  new  MIL-STD,  while  retaining  the  advanced  features 
currently  available  in  the  system.  This  is  a  major  task  that  will  require 
significant  redesign  of  the  database  architecture,  with  corresponding  ripple 
effects  throughout  the  on-line  system,  batch  system,  reporting  system,  and 
documentation. 

Transportability 

The  ALSAR  Is  currently  designed  to  utilize  the  Integrated  Database 
Management  System  (IDMS)  developed  by  Cullinet  Corporation.  As  a  result, 
the  ALSAR  system  is  transportable  only  to  locations  that  have  a  compatible 
operating  hardware  and  software  environment. 

Future  UDB  development  efforts  should  include  an  investigation  of  the 
technical  and  economic  advantages  and  disadvantages  of  system  transport¬ 
ability.  The  effort  should  consider  alternatives  that  range  from  maximum 
to  minimum  transportability,  and  evaluate  the  global  impact  of  basic 
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changes  in  requirements  by  the  Government,  standardization  desired  by  the 
Government,  achieving  closed-loop  UDB  objectives,  and  other  relevant  factors. 

Word-Processing  Capability 

The  need  exists  for  an  ALSAR  word-processing  capability  for  narrative 
data  in  the  LSAR  database.  Future  UDB  efforts  should  include  a  task  to 
investigate  and  develop  an  optimal  and  generic  interface  capability  between 
the  ALSAR  and  currently  available  word-processing  systems.  This  capability 
would  be  a  useful  and  cost-effective  tool  for  those  responsible  for 
accomplishing  LSA/LSAR  on  any  acquisition  program. 

Functional  Users  Guide 

There  is  a  critical  need  for  a  detailed  manual  to  instruct  functional 
area  users  on  the  use  of  the  ALSAR  in  the  LSA  process  for  any  given  weapon 
system  or  equipment  program.  While  the  DED,  DEI,  and  Users  Guide  were 
developed  for  the  ALSAR,  a  much  more  detailed  LSA  manual  is  needed.  Although 
MIL-STD-1388-2A  provides  an  enormous  amount  of  useful  information,  it  does 
not  adequately  address  this  specific  need.  The  Naval  Air  Systems  Command 
(NAVAIR)  00-25-401,  "Maintenance  Planning  and  Analysis  Program  Guide,"  is 
an  excellent  example  of  what  is  needed. 

ACDF 

The  ACDF  system  described  in  Section  IV  has  been  initially  developed 
and  tested,  but  has  not  been  validated.  The  system  represents  a  good  start, 
but  additional  development  work  is  needed  to  satisfy  objectives  1,  2,  3  and 
8  shown  in  Section  II,  Figure  1. 

Load  Data 

In  future  UDB  efforts,  the  ACDF  should  be  loaded  with  actual  data  for 
several  aircraft  MDSs.  If  the  Air  Force  plans  to  use  the  UDB  in  the  future 
to  support  a  specific  new  aircraft  weapon  system  acquisition  program,  the 
ACDF  should  be  loaded  with  data  about  similar  aircraft  MDSs  that  are  currentl 
operational . 


Interface  Programs 

The  capability  is  needed  to  enable  users  to  identify  a  BCS  in  the 
ACDF  and  to  have  the  system  automatically  produce  a  BCS  output  tape  in  ALSAR 
format.  This  capability  addresses  Objective  3  shown  in  Figure  1  and  dis¬ 
cussed  in  Section  II.  The  programs  required  to  achieve  this  capability  would 
also  satisfy  Objective  7  shown  in  Figure  1.  Future  UDB  development  efforts 
should  include  this  important  work.  In  addition,  continued  work  is  needed 
to  refine  and  test  the  interface  programs  to  process  and  load  D056E  and 
V AMO SC  data. 

Trend  Data  Graphics 

Although  the  on-line  retrieval  and  display  capabilities  discussed  in 
Section  IV  have  been  developed,  there  is  a  need  for  the  capability  for 
on-line  retrieval  and  display  of  R&M  trend  data  with  graphics. 

OT&E  INTERFACE 

The  prototype  UDB  effort  included  an  investigation  of  AFOTEC  require¬ 
ments  for  aircraft  suitability  testing  during  OT&E.  Future  UDB  development 
efforts  should  implement  the  findings  of  this  effort.  Specifically,  the 
ALSAR  and  ACDF  should  be  modified  to  provide,  as  a  minimum,  the  additional 
data  elements  identified  in  the  investigation  of  AFOTEC  requirements. 

INSTALL  AND  DEMONSTRATE  UDB 

In  future  UDB  development  efforts  the  current  ALSAR  and  ACDF  systems 
should  be  installed,  tested,  and  demonstrated  in  a  Government  computer 
facility  at  Wright-Patterson  AFB,  Ohio.  Subsequently,  modifications  and 
enhancements  should  be  installed,  tested,  and  demonstrated.  Software 
maintenance  should  also  be  provided  throughout  the  UDB  development  effort. 

COMPUTER-AIDED  DESIGN  (CAD) 


The  ACDF  and  ALSAR  system  of  the  UDB  represent  significant  computer 
tools  to  aid  in  the  design  and  systems  engineering  process.  The  UDB  does 


not  accomplish  the  function  of  modern  CAD  systems  used  to  explore  alterna¬ 
tives  and  to  establish  the  actual  design  of  (a)  airframe  structure,  mold 
lines,  compartments,  and  assemblies,  (b)  electronic  circuit  boards  and  com¬ 
ponents,  and  (c)  the  many  other  uses  for  primary  hardware,  support  equipment, 
and  facility  design. 

In  future  UDB  efforts  it  is  recommended  that  R&D  be  conducted  to 
investigate  alternative  approaches  for  developing  a  generic  interface 
between  the  UDB  and  various  CAD  systems  currently  available.  The  purpose 
of  such  an  interface  would  be  to  provide  an  improved  mechanism  whereby 
useful  R&M  and  logistics  support  related  information  is  provided  to  the 
design  engineer  such  that  logistics  factors  may  influence  design  activity  and 
decisions  that  occur  in  the  early  planning  and  throughout  the  design  process. 
Following  this  effort,  the  development  of  promising  alternatives  should  be 
pursued . 
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CSEL 
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DARCOMP 

DED 
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Automated  Data  Processing 
Air  Force  Base 
Air  Force  Guide 

Air  Force  Human  Resources  Laboratory 
Air  Force  Logistics  Command 
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Air  Force  Operational  Test  and  Evaluation  Center 
Automated  Logistics  Support  Analysis  Record 
American  National  Standard  Institute 
Baseline  Comparison  System 
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DOD 


Department  of  Defense 


DODD 

FMECA 

HDR 

How  Mai 

IDMS 

ILS 

LOOM 

LRU 

LSA 

LSACN 

LSAR 

MDCS 

MDS 

MIL-STD 

MMH/FH 

MOD-METRIC 

MPN 

MRSA 

NRLA 

NSN 

06.S 

ot&i-: 

PER 


Department  of  Defense  Directive 

Failure  Modes,  Effects,  and  Criticality  Analysis 
Historical  Data  Repository 
How  Ma 1 f unct ioned 

Integrated  Database  Management  System 

Integrated  Logistics  Support 

Logistics  Composite  Model 

Line  Replaceable  Unit 

Logistics  Support  Analysis 

Logistics  Support  Analysis  Control  Number 

Logistii-s  Support  Analysis  Record 

Maintenance  Data  Collection  System 

Mission,  Design,  and  Series 

Military  Standard 

Maintenance  Manhours  per  Flying  Hour 
A FIX  Spares  Provisioning  Model 
Manufacturer 's  Part  Number 

UAKCOM  Materiel  Readiness  Support  Activity 

Network  Repair  Level  Analysis 

National  Stock  Number 

Opor.it  ion  and  Support 

Operational  Test  and  Evaluation 

Parametric  Estimating  Relationship 


PMIJ 


Program  Management  directive 


PPFS 


Product  Performance  Feedback  System 


PPL 

- 

Provisioning  Parts  List 

R&M 

- 

Reliability  and  Maintainability 

SEN 

- 

Standard  Equipment  Nomenclature 

Seq.  No. 

- 

Line  Sequence  Number 

SERD 

- 

Support  Equipment  Recommendations  Document 

SRD 

- 

Standard  Reporting  Designator 

SRU 

- 

Shop  Replaceable  Unit 

SSC 

- 

Skill  Specialty  Code 

TSO 

- 

Time  Sharing  Option 

UC 

- 

Update  Code 

UDB 

- 

Unified  Database 

VAMOSC 

- 

Visibility  and  Management  of  Operational  Support  Cost 

VSAM 

- 

Virtual  Storage  Access  Method 

WBS 

_ 

Work  Breakdown  Structure 

WUC 


Work  Unit  Code 
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APPENDIX  B 


ACDF  ON-LINE  DATA  SCREENS 


In  Section  IV  the  ACDF  records  are  listed  in  Table  5, 
and  the  on-line  menu  screen  used  to  retrieve  these 
records  is  shown  in  Figure  19.  This  appendix  contains 
the  CRT  terminal  screens  for  several  ACDF  records.  The 
information  will  be  presented  in  the  order  shown  for 
each  record.  Since  all  of  the  information  in  a  record 
may  not  fit  on  a  single  screen,  the  system  will  instruct 
the  user  when  additional  information  is  avaiable  in  a 
record.  The  user  would  then  hit  the  ENTER  key  on  the 
terminal  to  display  the  "next  page"  of  information. 
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ENGINE  RECORD 


Display  Format: 


SOURCE  FOR  THIS  DATA  IS  FROM  AFG-3  DATED  GUN  59 
ENGINE:  TYPE  TURBOJET  MODEL  NUMBER  J57-P-43W 

ENGINE  MANUFACTURER  PRATT  &  WHITNEY  150-HR-QUAL-TEST.  MAR56 

PRODUCTION  STATUS:  OUT  OF  PRODUCTION 

NUMBER  OF  ENGINE  PRODUCED  741  AT  AN  AVERAGE  COST  OF  S  205.135 
COMPRESSOR  TYPE  IS  COMPOUND ,  TWO-SPOOL  AXIAL  WITH  16  STAGES. 
TYPE  OF  FAN 

COMPRESSOR  STAGES  -  LP  ROTOR  9 

-  LP  FAN  0 

-  HP  ROTOR  7 

NOMINAL  PRESSURE  RATIO  0.0 

NOMINAL  BY  PASS  RATIO  0.00:1. 

MAM  DESIGN  PRESSURE  RATIO  OVERALL  12.00:1. 

FAN  .00:1. 


L?  ROTOR  .00:1. 

HP  ROTOR  .00:1. 


0.0  % 

180  LB/SEC. 

0  LB/SEC. 

0  LB/SEC. 

ANNULAR  OUTER  /  S  FLOW  THROUGH  CAN 
AXIAL  -  DUAL  ROTOR 
3 
2 


MAX  ALLOWABLE  BLEED  AIR 
MAX  RATED  AIR  FLOW 
MAX  RATED  AIR  FLOW  -  FAN 
MAX  RATED  AIR  FLOW  -  COMP 
COMBUSTION  CHAMBER  TYPE 
TURBINE  TYPE 
TUR5INE  TOTAL  STAGES 

LP  ROTOR  STAGES 
HP  ROTOR  STAGES 
MAX  RATED  TUR3  INLET  TEMP/SIS 
MAX  ALLOWABLE  TURS  INLET  TEMP/SLS 
TURBINE  COOLING 
EXHAUST  NOZZLE  TURBINE 
AFTERBURNER  TYPE 
MAX  EXHAUST  EXIT  TEMP  /  SLS 
TYPE  OF  IGNITION 
ACCESSORY  DRIVE  PROVISION 
THRUST  TO  WEIGHT  RATIO 
LENGTH  -  OVERALL 
DIAMETER  -  NOMINAL 
AFTERBURNER  DIAMETER  NOMINAL 
ENGINE  WEIGHT  (DRY) 

ENGINE  WEIGHT  (WET) 

GUARANTEED  RATINGS 
(LB) 

MAXIMUM  11200 
MILITARY  11200 
NORMAL  9500 
ABSOLUTE  ALTITUDE 
LIMITING  MACH  NR  AT  5L 


1 

1600  DEGREES  F 
0  DEGREES  F 
NONE. 

FIXED  AREA. 

NONE 

0  DEGREE5  F 

LOW  TENSION,  HIGH  FREQUENCY  GLA. 
0 

0.00:1. 

167.3  IN. 

38.9  IN. 


0.0  IN. 

3370  LB. 

0  LB. 

AT  STATIC  SEA  LEVEL  STANDARD  CONDITIONS. 
(LP/HP)  (LB/HR/LB)  MAX  (LB/SEC) 
06400/09650  0.775  0  0 

06400/09650  0.775  0  0 

06100/09350  0.765  0  0 

55,000  FT. 

O.B 


INN) 


R  CKAM3 


ACD2 ,  2 


THE  AIRCRAFT(S)  USING  THIS  ENGINE  ARE 


AIRCRAFT 

SRD 

ENGINE 

SRD 

B-52F 

ABF 

J57-P-43W 

XBY 

B-52G 

ABG 

J57-P-43W 

XB1 

KC-135A 

ACX 

J57-P-43W 

XJD 
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HYDRAULIC  A  PNEUMATIC  POKER  SUPPLY  SUBSYSTEM  RECORD 


Display  Format: 


HYDRAULIC  &  PNEUMATIC  POWER  SUPPLY 
FOR  AIRCRAFT  XXXXXXX  (SRD  XXX) 


DATE  99/99/95 


HYDRAULIC  SYSTEM  DESIGN 


HYDRAULIC  SYSTEM  3-DIGIT  UUC 
HYDRAULIC  SYSTEM  4-DIGIT  WUC 
HYDRAULIC  SYSTEM  5-DIGIT  WUC 


99 

999 

9999 


HYDRAULIC  SYSTEMS  -  TOTAL 
HYDRAULIC  SYSTEMS  -  ENGINE  DRIVEN 
HYDRAULIC  SYSTEMS  -  ELECTRICAL  DRIVEN 
TOTAL 
ENGINE 
ELECTRICAL 


HYDRAULIC  PUMPS 
HYDRAULIC  PUMPS 
HYDRAULIC  PUMPS 


HYDRAULIC  SUPPORTED  SUBSYSTEM 


9 

9 

9 

99 

99 

99 

99 


HYDRAULIC 
HYDRAULIC 
HYDRAULIC 
HYDRAULIC 
HYDRAULIC 
NUMBER  OF 
HYDRAULIC 
HYDRAULIC 
HYDRAULIC 
HYDRAULIC 
HYDRAULIC 
HYDRAULIC 
HYDRAULIC 
HYDRAULIC 
HYDRAULIC 
HYDRAULIC 
HYDRAULIC 


PUMP  FLOW  -  ENGINE 

PUMP  PRESSURE  -  ENGINE 

PUMP  FLOW  -  ELECTRICAL 

PUMP  PRESSURE  -  ELECTRICAL 

TANKS  CAPACITY 

HYDRAULIC  TANKS 

SYSTEM  PRESSURE  -  MAX 

PUMP  RPM  -  ENGINE  RATIO 

TANK  PRESSURE 

PUMP  RPM  -  ELECTRICAL 

PUMP  -  AUXILLARY 

PUMP  FLOW  -  AUXILLARY 

PUMP  PRESSURE  -  AUXILLARY 

SYSTEM  OPERATING  TEMPERATURE  - 

MOTORS  HOURS 

VALVES 

FILTERS 


MAX 


99 

999 

99 

999 

999 

99 

999 

.999 

99 

9999 

9 

99 

999 

999 

99 

999 

999 


pneumatic  poker  source  xxxhxxnxhxhhxhxxmxhh: 

PNEUMATIC  CYLINDERS  -  NUMBER 
PNEUMATIC  SYSTEM  -  NUMBER 
PNEUMATIC  PRESSURE  -  MAXIMUM 
PNEUMATIC  SYSTEM  COMPONENTS 


KXXXHXX 

9 


9999 

99 


HYDRAULIC  &  PNEUMATIC  SUBSYSTEM  WEIGHT 

HYDRAULIC  &  PNEUMATIC  GROUP  WEIGHT . 

HYDRAULIC  SUBSYSTEM  WEIGHT . 

PNEUMATIC  SUBSYSTEM  WEIGHT . 


9999 


HYDRAULIC  AND  PNE’JMATIC  SUPPLY  WORK  UNIT  CODES 
WORK  UNIT 

CODES  NOMENCLATURE  NATIONAL  STOCK  NUMBER 


45000 
4SXXX 
4SXXX 
4SXXX 
4  5  XXX 
4  5  XXX 
45XXX 


HYDRAULIC  AND  PNEUMATIC  POKER 
XHXHHXHXXHXXXHXXXXHXXXXXXXHHXX 
XXXXXXXXXXXXXXXXXXXXXXXHXHXHHX 
XXXXXXXXXXXXXXXXXXXXXXMXXXXXHX 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


xxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxx 


_94_ 


2 


RT/CCST 


RECORD 


CODE:  OSC 

RECORD  NAME :  OPERATIONAL  SUPPORT/CCST 
Additional  Input  Requirements 

The  user  will  be  prompted  for  the  aircraft  MDS  and  then  for  the  code  for 
the  desired  sub-record  as  follows: 

CODE  SU3-REC0RD  HAKE 

1  -  AIRCRAFT  LEVEL/AFR  300-16,  FORMAT  4  DATA 

2  -  WORK  CENTER  3Y  AIRCRAFT  DATA 

3  -  SUPPORT  COST  BY  WUC  DATA 

4  -  RAM  3Y  WUC  DATA 

5  -  MAINTENANCE  ACTION  BY  WUC  DATA 


1.  AIRCRAFT  LEVEL/AFR  800-16,  FORMAT  4  DATA 

When  code  1  is  entered,  the  data  elements  listed  below  for  this  sub- 
record  will  be  displayed  as  shown  in  the  display  format. 


Display  Format: 

FOR  AIRCRAFT  MDS  JQQCCflQC 

FLYING  HOURS  999999  SORTIES  99999  LANDINGS  99999 

FROM  DAY  999  OF  9999  < YEAR )  TO  DAY  999  OF  9999  (YEAR) 


MHH/FH  *  KUH/SORTIE 


* 

ON-EQUI? 

SHOP 

TOTAL  * 

OM-SOUIP 

TOTAL  * 

PREVENTIVE  MAINTENANCE 

PREVENTIVE 

999.9 

999.9 

999.9 

999.9 

999.9 

01  GENERAL  SUPPORT 

999.9 

999.9 

999.9 

999.9 

999.9 

02  GENERAL  SUPPORT 

999.9 

999.9 

999.9 

999.9 

999.9 

05  GENERAL  SUPPORT 

999.9 

999.9 

999.9 

999.9 

999.9 

06  GENERAL  SUPPORT 

999.9 

999.9 

999.9 

999.9 

999.9 

07  GENERAL  SUPPORT 

999.9 

999.9 

999.9 

999.9 

999.9 

09  GENERAL  SUPPORT 

999.9 

999.9 

999.9 

999.9 

999.9 

SUBTOTAL  -  GENERAL  SUPPORT 

999.9 

999.9 

999.9 

999.9 

999.9 

03  SCHEDULE  INSPECTIONS 

999.9 

999.9 

999.9 

999.9 

999.9 

04  SPECIAL  INSPECTIONS 

999.9 

999.9 

999.9 

999.9 

999.9 

SUBTOTAL  -  INSPECTIONS 

999.9 

999.9 

999.9 

999.9 

999.9 

TOTAL 

999.9 

999.9 

999.9 

999.9 

999.9 

CORRECTIVE  MAINTENANCE 

INHERENT  MALFUNCTIONS 

999.9 

999.9 

999.9 

999.9 

999.9 

INDUCED  MALFUNCTIONS 

999.9 

999.9 

999.9 

999.9 

999.9 

OTHER  MALFUNCTIONS 

999.9 

999.9 

999.9 

999.9 

999.9 

SUBTOTAL  ALL  MALFUNCTIONS 

999.9 

999.9 

999.9 

999.9 

999.9 

NO  DEFECT 

999.9 

999.9 

999.9 

999.9 

999.9 

TOTAL  CORRECTIVE  MAINT 

999.9 

999.9 

999.9 

999.9 

999.9 

PRODUCTION  IMPROVEMENT  (TCTO) 

999.9 

999.9 

999.9 

999.9 

999.9 

TOTAL  BASE  LEVEL  MAINTENANCE 

999.9 

999.9 

999.9 

999.9 

999.9 

-95- 


2.  WORK  center  ev  aircraft  data 


When  code  2  is  entered,  the  data  elements  listed  below  for  this  sub¬ 
record  will  be  displayed  as  shown  in  the  display  format.  A  display  for 
each  applicable  work  center  will  be  presented. 


Display  Formats 

WORK  CENTER  DATA  FOR  AIRCRAFT  .‘!DS  NXICCflC: 

FLYIH3  HOURS  999999  SORTIES  99999  LANDINGS  99599 
FROM  DAY  999  OF  9999  (YEAR)  TO  DAY  999  OF  9999  (YEAR) 


WORK  CEKTER  TOTAL  MANHOURS  TOTAL  ELAPSED  TIME  MAINTENANCE  ACTIONS  MTS.NA 
H2112  999999.9  999999.9  999999  9995.9 

MEAN  MAN  HOURS/ACTIOM  KEAN  ELAPSE  TIME/ACTION  MEAN  CREW  SIZE 
9999.9  9999.9  99.9 

OFF-EQUIPKEKT 

WORK  CEKTER  TOTAL  MANHOURS  TOTAL  ELAPSE  TIME  MAINTENANCE  ACTIONS 
H2112  999999.9  999999.9  999999 

MEAN  MAN  HOURS/ACTION  MEAN  ELAPSE  TIME/ACTION  MEAN  CREW  SIZE 
9999.9  9999.9  99.9 


ON-EQUIPMENT 

WORK  CENTER  TOTAL  MANHOURS  TOTAL  ELAPSED  TIME  MAINTENANCE  ACTIONS  KT3HA 
K2100  892.0  682.0  20  4.6 

MEAN  KAN  HOURS/ACTION  MEAN  ELAPSE  TIKE /ACTION  MEAN  CREW  SIZE 
44.6  34.1  1.3 

OFF-EQUIPMENT 

WORK  CENTER  TOTAL  MANHOURS  TOTAL  ELAPSE  TIME  MAINTENANCE  ACTIONS 

K2100  202.0  178.0  14 

MEAN  MAN  HOURS/ACTION  MEAN  ELAPSE  TIME/ACTION  MEAN  CREW  SIZE 
14.4  12.7  1.1 


NOTE t  The  first  work  center  example  shows  field  sizes  (9's) 
far  the  data  elements.  The  second  shows  actual  data 
from  a  C-5A  work  center. 


3.  SUPPORT  COST  SV  WUC  DATA 


When  code  3  is  encered,  machine  prompts  user  to  enter  NUC  of  mte 
When  entered,  the  data  elements  listed  below  for  this  sub-report  w: 
displayed  as  shown  in  the  display  format.  The  user  may  enter  a  2, 
or  5  digit  WUC. 


Display  Format: 

OPERATIONAL  AND  SUPPORT  COST  DATA  DATE  95/9? 

REPORTING  PERIOD  FROM  99-99  THRU  95-99 

AIRCRAFT  KDS  HXXXXXH  WUC  XXXXX  XXXXXXXXXXXXXXXXXXXX 

NEXT  HIGHER  A35ENSLY  WORK  UNIT  CODE  XXXXX 

NATIONAL  STOCK  NUMBER  XXXXXXXXXXXXXXX 

QUANTITY  PER  APPLICATION  999  RESPONSIBLE  ALC  C 


COST 

BASE 

DEPOT 

CONDEMNATION  SPARES 

S9, 999, 999 

S999 , 999 

DIRECT  MATERIAL 

59,999,999 

5999,999 

EXCHANGEABLE  MOD  CLASS  IV 

S9, 999, 999 

S999 , 999 

EXCHANGEABLE  HOD  CLASS  V 

S9, 999, 999 

5999 , 999 

EXCHANGEABLE  REPAIR 

59,999,999 

S999.999 

MATERIAL  MANAGEMENT  OVERHEAD  S9, 999, 999 

S999 , 999 

OFF  EQUIPMENT  LABOR 

59,999,999 

OFF  EQUIPMENT  OVERHEAD 

59,999,999 

ON  EQUIPMENT  LA30R 

59,999.999 

ON  EQUIPMENT  OVERHEAD 

59,999,999 

SUPPLY  MANAGEMENT  OVERHEAD 
DEPOT  LABOR  COST 

59,999,999 

S999.999 

DEPOT  LABOR  HOURS 

5999,999 

DEPOT  HUMBER  OF  OPERATIONS 

5999,999 

DEPOT  OTHER  COST 

2ND  DEST.  TRANSPORTATION 

S9, 999, 999 

S999.999 

TOTAL  WORK  UNIT  CODE 

S999 , 999 , 999 

S9, 999, 999 

NUMBER  OF  PARTS  CONDEMNED 


999,999 


Xjl1T\ 


OPERATIONAL  SUPP CRT/CCST  RECORD 


4.  RAM  BY  WUC  DATA 

When  code  4  is  entered,  "he  aach:n*  prompts  the  user  to  enter  the  WUC  c: 
interest.  When  entered,  the  data  elements  listed  below  for  this  sub¬ 
record  will  be  displayed  as  shown  in  the  display  format.  The  user  may 
enter  a  2,  3,  4,  or  5  digit  WUC. 


Display  Format: 

R&I-l  DATA  BY  WUC 

REPORTING  PERIOD  FROM  (MONTH/ YEAR)  TO  (MONTH/YEAR) 

AIRCRAFT  MDS  XXXXXXX  WUC  XXXXX  XXXXXXXXXXXXXXXXXXXX 
NEXT  HIGHER  ASSEMBLY  WORK  UNIT  CODE  XXXXX 
NATIONAL  STOCK  NUMBER  XXXXXXXXXXXXXXX 

QUANTITY  PER  APPLICATION  999  RESPONSIBLE  ALC  CODE 


REPAIRABLE  THIS  STATION 

999,999 

NOT  REPAIRABLE  THIS  STATION 

999.999 

MEAN  TIMES  BETWEEN  MAINTENANCE 

( MT3M ) 

MTBM  STANDARD  DEVIATION 

INDUCED  99999 

99.999 

INHERENT  99999 

99.999 

NO  DEFECT  99999 

99.999 

OTHER  99999 

99.999 

PREVENTIVE  99999 

99.999 

OFF  EQUIPMENT 

INDUCED  MANHOURS 

999,999 

INHERENT  MANHOURS 

999,999 

NO  DEFECT  MANHOURS 

999,999 

OTHER  MANHOURS 

999,999 

PREVENTIVE  MANHOURS 

999,999 

TOTAL  MANHOURS 

9,999,999 

MAINTENANCE  ACTIONS 

999,999 

MEAN  CREW  SIZE 

99.9 

STANDARD  DEVIATION 

99.999 

MEAN  MANHOURS  TO  REPAIR 

9Q  QQQ  q 

STANDARD  DEVIATION 

99.999 

MEAN  ELAPSED  TIME  TO  REPAIR 

99,999.9 

STANDARD  DEVIATION 

99.999 

ON  EQUIPMENT 

INDUCED  EVENTS 

999,999 

INDUCED  MANHOURS 

999  999 

INHERENT  EVENTS 

999,999 

INHERENT  MANHOURS 

999  999 

NO  DEFECT  EVENTS 

999,999 

NO  DEFECT  MANHOURS 

999,999 

OTHER  EVENTS 

999,999 

OTHER  MANHOURS 

999.999 

PREVENTIVE  EVENTS 

999,999 

PREVENTIVE  MANHOURS 

999,999 

TOTAL  MANHOURS  9,999.999 

MEAN  CREW  SIZE 

99.9 

STANDARD  DEVIATION 

go  999 

MEAN  ELAPSED  TIME  TO  REPAIR 

99,999.9 

STANDARD  DEVIATION 

99  a  999 

MEAN  MANHOURS  TO  REPAIR 

99,999.9 

STANDARD  DEVIATION 

99.999 

OPERATING  TIME 

999,999 

STANDARD  DEVIATION 

99 . 999 

NOTE:  Standard  Deviation  provided  if  available. 
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s.  maintenance  actiom  by  wjc  data 

When  code  5  is  entered,  the  machine  prcnpts  the  user  to  enter  the  WUC  of 
interest.  When  entered,  the  data  elements  listed  below  for  this  sub- 
record  will  be  displayed  as  shown  in  the  display  format.  A  display  will 
be  presented  for  each  set  of  Action  Taken,  How  Malfunctioned,  ar.d  Type 
How  Malfunctioned  Codes  reported.  A  summary  of  all  the  displays  is 
presented  at  the  er.d  for  the  WUC  selected.  The  user  may  enter  a  2,  E, 
4,  or  5  digit  WUC. 


Display  Format: 

MAIMTENAMCE  ACTIOM  DATA 

AIRCRAFT  MDS  XXXXXXX  WUC  XXXXX 

FLYING  HOURS  999999  SORTIES  99999  LANDINGS  9=°99 
FROM  (DAY/ YEAR)  TO  (DAY/ YEAR) 


WORK  UHIT  CODE:  XXXXX  ACTION  TAKEN:  X  HOW  HAL  CODE:  999  TYPE  HOW  HAL:  9 
UNSCHEDULED  MAINTENANCE  "* 


MAINTENANCE 

MEAN 

MAINTENANCE 

MTSMA 

MANHOURS 

ELAPSED  TIME 

CREW  SIZE 

ACTIONS 

9999.9 

9999.9 

999.9 

99.9 

9999 

**  SCHEDULED 

MAINTENANCE  ** 

MAINTENANCE 

MEAN 

MAINTENANCE 

MTBMA 

MANHOURS 

ELAPSED  TIME 

CREW  SIZE 

ACTIONS 

9999.9 

9999.9 

999.9 

99.9 

9999 

WORK  UNIT 

CODE:  6 SABO 

ACTION  TAKEN:  Q 

HOW  MAL  CODE: 

799  TYPE  HOW 

**  UNSCHEDULED  MAINTENANCE 

** 

MAINTENANCE 

MEAN 

MAINTENANCE 

MTBMA 

MANHOURS 

ELAPSED  TINE 

CREW  SIZE 

ACTIONS 

.0 

.7 

.7 

1.0 

0 

**  SCHEDULED 

MAINTENANCE  ** 

MAINTENANCE 

MEAN 

MAINTENANCE 

MTBMA 

MANHOURS 

ELAPSED  TIME 

CREW  SIZE 

ACTIONS 

.0 

.0 

.0 

.0 

0 

-  SUMMARY  OF  MAINTENANCE  DATA  - 

AIRCRAFT  MDS  C-5A  WORK  UNIT  CODE  6 SAB 
**  UNSCHEDULED  MAINTENANCE  *' 


MTBMA 

MAINTENANCE 

MANHOURS 

ELAPSED  TIME 

MEAN  MAINTENANCE 

CREW  SIZE  ACTIONS 

93.2 

1.4 

1.4 

1.0 

1 

**  SCHEDULED 

MTBMA 

MAINTENANCE  ** 
MAINTENANCE 
MANHOURS 

ELAPSED  TIME 

MEAN  MAINTENANCE 

CREW  SIZE  ACTIONS 

.0 

.0 

.0 

.0 

0 

NOTE:  The  first  example  shews  the  field  sizes  for  the 

maintenance  action  data  elements.  The  second  example 
is  actual  C-5A  data.  The  third  example  shows  a  summary 
of  maintenance  actions  from  actual  C-5A  data. 
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